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FOREWORD 

Hughes  Ground  Systems  Group  is  pleased  to  submit  this 
Task  2 Report,  identified  as  CDRL  Item  A002,  to  the  David  W. 
Taylor  Naval  Ship  Research  and  Development  Center  (DTNSRDC), 
Bethesda,  Maryland,  in  accordance  with  Contract  N00600-76-C-1352 
for  the  Navy  Technical  Information  Presentation  Program  (NTIPP). 
This  contract  is  under  the  technical  management  of  Mr.  R.  A.  Sulit 
and  Mr.  J.  J.  Fuller,  both  of  DTNSRDC  Code  186A. 

Task  2 is  the  second  of  seven  contractual  tasks  in  NTIPP 
Phase  I - Systems  and  Feasibility  Tradeoff  Analyses.  The  purpose 
of  Task  2 is  to  establish  the  initial  NTIPP  functional  requirements 
for  preliminary  baseline  development  (Task  3).  These  require- 
ments will  serve  as  a threshold  which  must  be  satisfied  by  all  viable 
alternatives  before  such  alternatives  qualify  for  consideration  in  the 
baseline  process. 

Performing  organization  personnel  who  participated  in  the 
Task  2 effort  and  with  the  preparation  of  this  report  include  the 
following  individuals,  with  principal  investigators  identified  by 
asterisk: 

J.  E.  Connell  (Program  Manager) 

D.  W.  Gater 
J.  W.  Kelsey 

*R.  J.  Kennihan  (User-Data  Match) 

*A.  Laicato  (Content  Generation,  Update,  and  Integration) 

*C.  E.  Marvin  (Data  Acquisition) 

H.  A.  McDougal 

*R.  C.  Sisman  (Content  Capture  and  Replication) 

*W.  L.  Taylor  (Distribution  and  Feedback) 

D.  R.  Wilkins 
W.  F.  Ziegler 
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Executive  Summary 


► 

1.  PROBLEM  ADDRESSED  BY  THE  TASK  2 EFFORT 


The  role  of  Task  2 is  to  establish  a set  of  requirements  which  suitably  constrain  the 
initiation  and  conduct  of  the  NTIPP  baselining  process.  This  Task  2 report  presents 
preliminary  NTIPP  requirements  which  have  been  subjected  to  Navy  review  and 
resultant  modification  before  final  issue. 

The  Navv  Technical  Information  Presentation  Program  INTIPP)  consists 
of  four  phases:  Phase  I — Systems  and  Feasibility  Trade-off  Analyses  (SFTOA); 
Phase  II-  System  Design,  Pilot  Testing,  and  Prototype  Specifications  Develop- 
ment: Phase  III  - Prototype  Development  and  Test;  and  Phase  IV-  Prototype 
Operation  and  Production  Specifications  Development.  This  report  documents 
Task  2,  Establishment  of  NTIPP  Requirements,  which  is  the  second  of  seven 
SFTOA  tasks  in  Phase  I. 

The  need  for  NTIPP  requirements  is  apparent  when  one  considers  that 
the  familiar  system  engineering  process  of  iterative  baselining  begins  with 
SFTOA  Task  3,  wherein  alternatives  are  synthesized  from  the  information  base 
of  Task  1 and  compared,  and  a preliminary’  selection  made  of  preferred  candi- 
date tachniques  at  the  lower  levels,  the  Research  Issue  level,  and  the  overall 
NTIPP  level.  To  avoid  design  divergence  through  inadvertent  consideration  of 
potentially  infeasible  or  inadequate  alternatives,  some  means  must  exist  for 
qualifying  potential  candidates  before  they  are  admitted  to  consideration.  The 
requirements  established  in  Task  2 serve  this  need  - they  represent  the  threshold 
which  all  alternatives  must  satisfy,  as  a minimum,  before  being  declared  to  be 
viable,  bona  fide  candidates  for  further  consideration  in  the  baselining  process. 

The  procedure  by  which  Task  2 requirements  came  into  existence  is 
straightforward.  Engineering  judgment  was  applied  to  the  information  base  pro- 
duced in  Task  1,  Analysis  of  Current  and  Proposed  Technical  Manual  Systems,* 
to  determine  areas  of  adequacy  and  deficiency,  and  a requirements  envelope 
developed  which  retained  the  areas  of  present/proposed  adequacy  while  imposing 
requirements  whose  subsequent  satisfaction  will  compensate  for  the  deficiencies 
and  gaps  in  coverage  exhibited  by  the  current  and  presently  proposed  technical 
manual  systems. 

The  requirements  developed  during  Task  2 ;ind  documented  herein  have 
undergone  Navy  review  between  the  issue  of  the  draft  ;md  final  versions  of  this 
Task  2 report. 


a 


*As  documented  in  NTIPP  CDRL  AOOI,  Task  1 Report,  Hughes  Aircraft  Company, 
Ground  Systems  Group,  Fullerton,  California,  dated  24  March  1977. 
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2.  APPROACH  TO  REQUIREMENTS  FORMULATION 


The  technical  approach  to  Task  2 is  based  upon  a continuation  of  the  application  of 
systems  engineering  methodology  to  the  NTIPP  research  activities,  as  begun  in 
Task  2.  Directly  or  indirectly,  all  NTIPP  requirements  are  traceable  back  to  the 
driving  constraints  of  the  Weapon  System  Acquisition  Process. 

The  role  of  Task  2 is  to  operate  on  the  information  base  produced  in 
Task  1 and  to  establish  a set  of  requirements  which  serve  to  screen  potential 
NTIPP  alternatives  (the  subject  of  Task  3),  rejecting  those  which  are  inadequate 
or  incompatible.  The  requirements  of  Task  2 therefore  serve  as  a control 
mechanism,  qualifying  potential  alternatives  for  further  consideration  within 
Task  3,  in  which  preliminary  selections  will  be  made  to  constitute  the  emerging 
baseline  for  NTIPP. 

The  principal  concern  in  establishing  NTIPP  requirements  is  that  they 
serve  to  assure  convergent  design  without  unduly  restricting  the  synthesis  of 
alternatives  - that  is,  they  neither  over-constrain  (lest  they  inadvertently  reject 
viable  alternatives)  nor  under-constrain  (lest  they  accept  unviable  alternatives 
into  consideration).  This  "over-specify/under-specify”  dilemma  is  a familiar 
confrontation  in  the  systems  engineering  discipline;  its  resolution  is  a matter  of 
engineering  judgment. 

It  should  be  noted  that  Tasks  1 and  2 were  performed  within  the  same 
7-month  timeframe  because  of  the  close  correlation  required.  A total  of  some 
75  man-months  was  expended  on  the  combined  effort,  of  which  about  20  are 
attributable  to  the  Task  2 portion. 

The  primary  catalyst  from  which  NTIPP  requirements  arise  is  the  set  of 
constraints  imposed  by  the  Weapon  System  Acquisition  Process  (WSAP).  NTIPP 
requirements  are  inherently  groupable  into  a hierarchy  by  noting  their  relative 
level  with  respect  to  the  WSAP.  Hence,  the  first-level  NTIPP  requirements  are 
those  which  react  directly  to  the  WSAP  constraints;  these  are  reactive  in  nature, 
and  exhibit  the  highest  degree  of  inflexibility  to  the  design  process.  The  second- 
level  requirements  are  those  which  are  derived  from  the  first-level  ones,  and 
the  process  of  deriving  further-level  requirements  is  continued  to  a level  of  con- 
venience. All  but  the  first-level  requirements  are  derived,  rather  than  reactive. 
Flexibility  of  the  requirements  is  inversely  related  to  the  level;  as  the  progression 
continues,  the  lower-level  requirements  are  treatable  in  increasingly  freer  fash- 
ion in  their  application  to  the  design  process. 

In  this  connection,  first-level  requirements  (directly  reactive  to  WSAP 
constraints)  are  presented  in  Section  3 of  this  report,  and  restated  in  Topic  4.9, 
together  with  the  second-level  requirements  which  represent  the  first  occur- 
rence of  derived  requirements.  Further  levels  of  derived  requirements  are 
represented  by  the  research  issue  requirements  in  each  case,  which  are  further 
extended  to  requirements  for  subfunctional  areas  where  appropriate. 
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Executive  Summary 


3 . SUMMARY  OF  TASK  2 CONC  LUSIONS  AND  RECOMMENDATIONS 


Conclusions  and  recommendations  drawn  from  the  conduct  of  Task  2 center  around 
the  need  for  earlier  involvement  of  MOTD  decision-making  in  the  VVSAP  cycle, 
and  for  better  definition  of  key  ILS  and  LSA  activities  to  enhance  their  interface 
with  the  MOTD  process. 

The  most  significant  conclusions  and  recommendations  involve  the  top- 
level  NTIPP  requirements  which  are  directly  reactive  to  the  constraints  of  the 
Weapon  System  Acquisition  Process  (WSAP).  While  lower-level  requirements 
can  be  applied  to  the  design  process  with  various  degrees  of  flexibility,  these 
top-level  requirements  are  relatively  inflexible.  Hence,  their  impaction  by 
existing  policies  and  procedures  becomes  a critical  matter  which  is  worthy  of 
incorporation  in  Task  2 conclusions  and  recommendations  even  where  the 
resolution  may  lie  outside  the  purview  of  NTIPP, 

Because  they  correspond  to  the  principal  WSAP  phases  of  concept 
formulation,  validation,  full-scale  development,  production,  deployment  and 
support,  the  top-level  NTIPP  requirements  presented  in  this  draft  Task  2 
report  are  organized  around  these  WSAP  phases.  Based  on  the  details  of  top- 
level  and  research  issue  level  requirements  included  in  the  body  of  this  report, 
the  following  are  the  chief  findings  resulting  from  the  Task  2 effort. 

Early  MOTD  Decision-Making  - System/equipment  decisions  made  in 
the  WSAP  concept  formulation  and  validation  phases  have  far-reaching  impacts 
on  the  MOTD  process  to  follow.  Yet,  MOTD  concerns  appear  to  have  little 
influence  during  these  phases  at  the  present  time.  Decisions  are  made  in  the 
interests  of  the  hardware  system  only,  and  arbitrarily  insofar  as  the  MOTD 
is  concerned.  As  a result,  the  supportability  of  the  hardware  system  is  left 
somewhat  to  chance,  with  the  emerging  MOTD  definition  performed  largely 
by  exclusion. 

It  is  recommended  that  a concerted  effort  be  directed  at  the  inclusion 
of  MOTD  concerns  in  the  initial  phases  of  the  WSAP,  to  achieve  deliberate 
compatibility  between  the  MOTD  and  the  hardware  system  it  must  support, 
during  the  formative  stages  when  such  compatibility  can  easily  be  attained. 
Otherwise,  it  may  not  be  possible  to  subsequently  compensate  for  inadvertent 
exclusion  of  MOTD  factors  within  the  system  procurement  cost  and  schedule 
limitations. 

ILS/ MOTD  Interface  Definition  - The  aforementioned  problem  of  MOTD 
involvement  in  the  early  WSAP  phases  is  aggravated  by  the  lack  of  specific 
"how-to"  instructions  for  Integrated  Logistics  Support  (ILS)  personnel  involved 
in  Logistic  Support  Analyses  (LSA)  during  the  WSAP  phases.  While  exhortations 
abound  to  accommodate  suitable  provisions  for  all  support  factors,  MOTD 
included,  the  existing  ILS  documentation  is  sadly  lacking  in  details  of  imple- 
menting such  provisions  (e.g.  , task  analysis,  job  analysis,  and  time-phasing  of 
both  with  respect  to  MOTD  decisions).  Without  firm  guidelines  for  considering 
MOTD  in  the  early  planning  activities,  it  is  unlikely  that  the  present  deficiencies 
can  be  readily  overcome.  It  is  recommended  that  steps  be  taken  by  the  Navy  to 
improve  and  augment  the  existing  ILS  governing  documents  by  including  speci- 
fic instructions,  guidelines,  and  steps  to  be  taken  to  insure  that  MOTD  issues 
are  adequately  taken  into  account  during  WSAP  concept  formulation  and  valida- 
tion phases. 

Qualification  Criteria  for  the  ILS  Team  - Another  shortcoming  of  exist- 
ing ILS  documentation  is  the  absence  of  criteria  for  personnel  involved  in  ILS 
actions  which  affect  MOTD.  Often,  the  ILS  planning  literature  refers  to  an 
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"ILS  Team,  " but  no  definition  exists  on  the  composition  of  this  team,  nor  on 
the  sources  from  which  personnel  are  to  be  drawn.  Moreover,  no  requirement 
is  levied  that  any  of  the  team  members  possess  specific  insight  and  knowledge- 
ability  of  MOTD.  While  this  need  may  be  filled  informally  by  a diligent,  percep- 
tive Program  Manager,  a clear  necessity  exists  to  codify  the  need  for  direct, 
MOTD-related  experience  factors  to  be  included  on  the  ILS  team. 

LSA/ Training/ MOTD  Interface  Coordination  — At  present,  the  conduct 
of  any  Head/Data/ Training  tradeoff  study  — the  cornerstone  of  the  user-data 
match  effort  incorporated  in  NTIPP  — would  be  greatly  hampered  by  the  lack 
of  coordinated  activity  by  the  LSA  personnel,  the  training  community,  and  those 
involved  with  preparation  of  MOTD.  Such  a tradeoff  must  be  based  upon  task 
analysis,  job  characteristics,  the  frequency,  criticality,  and  complexity  of 
maintenance  actions,  etc.  However,  the  current  ILS  approach  separately 
places  task  analysis  in  the  LSA  activity,  training  with  the  training  community, 
and  MOTD  in  the  "technical  manual  world." 

In  the  NTIPP  Task  1 report  (CDRL  A001),  it  was  noted  both  in  the  dis- 
cussions of  the  user-data  match  and  the  content  generation  research  issues  that 
the  training  community  has  insufficient  influence  on  the  presentation  method,  the 
format,  and  the  content  of  technical  manuals.  As  a result,  it  is  difficult  to 
assure  the  effective  use  of  technical  manuals  for  training  purposes  as  well  as  for 
maintenance.  However,  in  the  light  of  Task  2 requirements,  it  is  clear  that  such 
influence  must  exist  in  the  early  phases  of  the  WSAP,  and  that  coordination  must 
take  place  not  only  between  the  MOTD  and  training  activities  but  with  the  LSA 
activity  as  well. 

The  necessary  coordination  could  be  implemented  in  a variety  of  ways  — 
e.g. , mandatory  inclusion  of  a training  specialist  and  an  MOTD  engineer  on 
the  ILS  team,  or  by  the  requirement  to  secure  inputs  to  the  evolving  ILS  plans 
from  those  areas,  etc.  It  is  recommended  by  the  contractor  that  a suitable 
means  be  established  for  achieving  this  type  of  coordination  from  the  inception 
of  ILS  planning,  so  as  to  provide  the  framework  for  an  effective  Head/Data/Train- 
ing tradeoff  study  prior  to  adoption  of  constraints  which  prejudge  the  outcome 
of  such  a study. 


E-3  (E-4  BLANK) 


I 

* 

f* 


EXECUTIVE  SUMMARY 


1.  Pi'oblem  Addressed  by  the  Task  2 Effort E-0 

2.  Approach  to  Requirements  Formulation E-l 

3.  Summary  of  Task  2 Conclusions  and 

Recommendations E-2 

SECTION  1 - INTRODUCTION 

1.1  Objective 1-0 

1.2  Problem  Statement  and  Background 1-1 

1.3  Scope  and  Approach 1-2 

1.4  Limitations 1-3 

1.5  Plan  of  Report 1-4 

SECTION  2 - METHODOLOGY 

2. 1 Relationship  of  Task  2 to  the  Total  NTIPP  Effort 2-0 

2.2  Constraints  Bounding  the  Establishment  of  Preliminary 

NTIPP  Requirements 2-2 

SECTION  3 - TOP-LEVEL  NTIPP  REQUIREMENTS 


3. 1 Rationale  for  the  Development  of  NTIPP  Requirements 

in  the  Concept  Formulation  Phase  of  the  Weapon 

System  Acquisition  Process 3-0 

3.  2 Required  NTIPP  Actions  During  Weapon  System  Concept 

Formulation 3-2 

3.3  Rationale  for  Development  of  NTIPP  Requirements  in 

the  Validation  Phase  of  the  Weapon  System 

Acquisition  Process  3-4 

3.4  Required  NTIPP  Actions  During  Weapons  System 

Validation  Phase  . 3-6 

3. 5 Rationale  for  the  Development  of  NTIPP  Requirements 

in  the  Full-Scale  Development  Phase  of  the  Weapon 

System  Acquisition  Process 3-8 

306  Required  NTIPP  Actions  During  Weapon  System  Full- 

Scale  Development 3-10 

3.  7 Rationale  for  the  Development  of  NTIPP  Requirements 
in  the  Production/Deployment/Support  Phases  of 
the  Weapon  System  Acquisition  Process 3-12 

3.  8 Required  NTIPP  Actions  During  Weapon  System 

Production/Deployment/Support  Phases  3-14 

SECTION  4-  RESEARCH  ISSUE  LEVEL  NTIPP  REQUIREMENTS 

4. 1 User-Data  Match  Requirements  . 4-1 

4. 2 Data  Acquisition  Requirements 4-6 

4.3  Content  Generation  Requirements 4-12 

4.  4 Content  Capture  Requirements  . . 4-16 

4. 5 Content  Replication  Requirements 4-20 

4.6  Distribution  Requirements 4-24 

4.7  Update  Requirements  4-26 

4.  8 Feedback  Requirements  4-28 

4.9  Integration  Requirements  4-30 


iii 


CONTENTS  (Continued) 


SECTION  5 - REFINEMENT  AND  RATIFICATION  OF  NTIPP 
REQUIREMENTS 

5. 1 Provisions  for  Navy  Review  of  NTIPP  Requirements 

SECTION  6 - CONCLUSIONS 

SECTION  7 - RECOMMENDATIONS 

APPENDIX  A - REFERENCES 

APPENDIX  B - GLOSSARY 


iv 


ILLUSTRATIONS 


Figure 

2-1  Relationship  of  Task  2 to  Overall  NTIPP  Effort 2-1 

2- 2  Constraints  on  NTIPP  Requirements 2-3 

3- 1  Comparison  of  the  Weapon  System  Acquisition  Process  and 

Resultant  Actions  in  the  ILS  and  MOTD  Realms 3-1 

3-2  Relationship  of  MOTD  Events  to  WSAP  Actions  in  the 

Validation  Phase 3-5 

3-3  Relationship  of  MOTD  to  Systems  Development  in  the  Full- 

Scale  Development  Phase  of  the  WSAP 3-9 

3-4  Relationship  of  MOTD  to  System  Development  and  ILS  During 
the  Production  Deployment  and  Support  Phases  of  the  Weapon 
System  Acquisition  Process 3-13 


TABLES 

Table 

3-1  NTIPP  Requirements  Involving  the  Concept  Formulation 

Phase 3-3 

3-II  Requirements  Involving  the  Validation  Phase 3-7 

3— III  Requirements  Involving  the  Full-Scale  Development  Phase  . . . 3-11 

3- IV  Requirements  Involving  Production/Deployment/Support 

Phases  3-15 

4- 1  User-Data  Match  Requirements 4-4 

4-II  Data  Acquisition  Requirements 4-9 

4— III  Content  Generation  Requirements  4-13 

4-IV  Content  Capture  Requirements 4-18 

4-V  Replication  Requirements 4-22 

4-VI  Distribution  Requirements 4-25 

4-VII  Update  Requirements 4-27 

4-VIII  Feedback  Requirements 4-29 

4-EX  Integration  Requirements 4-31 


SECTION  1 
INTRODUCTION 


1.1  Objective  1-0 

1.2  Problem  Statement  and  Background  1-1 

1.3  Scope  and  Approach  1-2 

1.4  Limitations  1-3 

1.5  Plan  of  Report  1-4 


Section  1 - Introduction 


1.  1 OBJECTIVE 


The  objective  of  Tusk  2 is  to  establish  and  obtain  Navy  concurrence  for  a consistent 
set  of  NTIPP  requirements  which  can  properly  constrain  the  preliminary  baselin- 
ing in  Task  3.  These  requirements  have  been  derived  through  the  application  of 
engineering  judgment  to  the  information  base  produced  in  Task  1. 

Task  2,  Establishment  of  NTIPP  Requirements,  is  the  second  effort  in 
the  7-task  structure  of  NTIPP  Phase  I - Systems  and  Feasibility  Tradeoff 
Analyses  (SFTOA).  Task  2 has  two  distinct  objectives: 

(a)  To  establish  a consistent  set  of  requirements  for  NTIPP  (both  at  the 
top  or  "system"  level  and  at  the  research  issue  level)  which  fulfills 
the  need  for  a qualifying  control  mechanism  for  Task  3.  The  nature 
of  the  control  mechanism  is  defined  by  the  need  to  qualify  potential 
alternatives  which  present  themselves  in  satisfaction  of  NTIPP 
functions,  i.  e.  , a threshold  must  be  established  to  test  potential 
alternatives  before  they  are  even  admitted  to  consideration.  The 
requirements  documented  in  this  report  serve  this  need  by  imposing 
a collective  constraint  on  all  alternatives  synthesized  during  Task  3 
— a given  alternative  can  be  admitted  for  consideration  to  the  array 
from  which  a subsequent  selection  will  be  made  only  if  it  first  satis- 
fies all  of  the  stated  Task  2 Requirements. 

(b)  To  obtain  Navy  review,  modification  as  necessary,  and  concurrence 
for  these  requirements,  thereby  instituting  an  agreed-upon  basis  for 
proceeding  with  Task  3 and  the  balance  of  the  baseline  activities. 

In  this  light,  the  requirements  documented  in  this  final  issue  of  the 
Task  2 report  are  regarded  as  firm,  since  Navy  review  and  indicated 
corrections  have  now  been  made. 

The  source  data  from  which  the  requirements  in  the  Task  2 report  are 
drawn  is  the  information  base  produced  in  Task  1,  Analysis  of  Current  and 
Proposed  Technical  Manual  Systems  (CDRL  A001).  Engineering  judgement  has 
been  applied  to  the  results  of  Task  1,  resulting  in  a requirements  envelope  which 
retains  the  presently  adequate  provisions  and  proposals  for  improvement,  as 
well  as  levying  requirements  which  will  compensate  for  existing  gaps  in  coverage 
among  the  current  and  proposed  systems  studied. 


1.2  PROBLEM  STATEMENT  AND  BACKGROUND 


The  principal  concerns  in  NTIPP  requirements  generation  are  to  employ  the  proper 
degree  of  rigor,  and  to  elicit  sufficient  response  and  interaction  by  the  Navy  to  as- 
sure concurrence. 

Establishing  NTIPP  requirements  for  application  in  Task  3 baseline  de- 
sign is  a critical  step  in  the  development  process.  Care  must  be  exercised  to 
avoid  the  imposition  of  large  numbers  of  constraints  and  the  danger  of  limiting  the 
baseline  design  process  severely.  The  other  side  of  this  risk  is  to  postulate  broad 
design  requirements  resulting  in  an  unmanageable  number  of  alternative  ap- 
proaches. Requirements  constraints  are  subject  to  the  same  dangers  usually 
recognized  as  the  "overspecify  — underspecify  dilemma."  Another  concern  is 
that  one  can  easily  include  "requirements"  which  are  really  not  true  require- 
ments or  necessarily  significant  to  baseline  design. 

The  generation  of  appropriate  baseline  design  requirements  has  been  the 
overriding  concern  of  SFTOA  efforts  to  date.  This  is  the  sole  design  justification 
for  the  conduct  of  Task  1.  While  the  contractor  has  lent  every  effort  to  provide 
a comprehensive  list  of  requirements  it  must  be  recognized  that  there  is  no 
"algebra"  (or  other  logical  construct)  which  can  be  employed  to  ensure  that  a 
complete  set  has  been  generated.  In  the  final  analysis,  informal  judgment  is 
the  only  source  available. 

"Ultimately  all  policies  are  made  and  all  weapons  systems  are  chosen  on 
the  basis  of  judgments.  There  is  no  other  way  and  there  never  will  be.  The 
question  is  whether  those  judgments  have  to  be  made  in  the  fog  of  inadequate  and 
inaccurate  data,  unclear  and  undefined  issues,  and  a wealth  of  conflicting  per- 
sonal opinions,  or  whether  they  can  be  made  on  the  basis  of  adequate,  reliable 
information,  relevant  experience,  and  clearly  drawn  issues. nl  The  conduct  of 
Task  1 provided  considerable  insight  to  the  requirements  currently  faced  by  the 
Navy  SYSCOMs  in  the  conduct  of  their  TM  business.  However,  the  contractor 
recognizes  that  even  the  most  rigorous  analysis  can  overlook  points  which  are 
evident  to  those  who  are  responsible  for  the  conduct  of  Navy  MOTD  activities  on 
a day-to-day  basis.  The  reader  is  invited  to  study  these  requirements,  comment 
upon  their  worth,  and  suggest  additions  or  deletions  where  appropriate.  Con- 
structive criticism  will  enable  the  baseline  design  to  proceed  with  maximum 
benefit. 
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1.3  SCOPE  AND  APPROACH 


The  scope  of  Task  2,  Establishment  of  NTIPP  Requirements,  was  bounded  by  the 
expenditure  of  about  20  man-months  of  effort  over  a 7-month  period.  The  overall 
approach  was  based  upon  formulating  a consistent  set  of  preliminary  requirements 
which  were  subject  to  Navy  review  prior  to  release. 

Schedule  and  Resources  Allocation  - The  timeframe  for  the  conduct  of 
Task  2 is  defined  as  beginning  with  the  inception  of  contractual  coverage  on 
24  June  1976,  and  culminating  with  the  delivery  of  the  Task  2 draft  report  on 
24  January  1977. 

Across  this  timeframe,  an  incremental  staffing  plan  provided  for  a 
research  force  ranging  from  6 to  18  individuals  who  concurrently  performed 
Tasks  1 and  2.  This  resulted  in  the  expenditure  of  approximately  75  man-months 
of  NTIPP  effort,  of  which  some  20  man-months  are  attributable  to  Task  2.  (Not 
included  in  these  figures  is  the  resource  allocation  to  the  NTIPP  Fleet  Survey 
of  TM  Users,  which  is  described  in  a separate  report,  the  draft  issue  of  which 
was  delivered  on  5 March  1977.) 

Approach  to  Requirement  Hierarchy  - The  purpose  of  a hierarchy  of 
requirements  is  to  allow  the  designer  place  proper  focus  on  each  individual 
requirement  within  the  context  of  its  importance  to  the  development  of  the 
NTIPP  baseline. 

NTIPP  requirements  are  inherently  groupable  into  such  a hierarchy  by 
noting  their  relative  level  with  respect  to  the  driving  requirements  of  the  Weapon 
System  Acquisition  Process  (WSAP).  Hence,  the  first-level  NTIPP  requirements 
are  those  which  result  directly  from  the  driving  requirements  of  the  WSAP.  These 
are  reactive  in  nature,  and  exhibit  the  highest  degree  of  inflexibility  to  the  design 
process.  The  second-level  requirements  are  those  which  are  derived  from  the 
first-level,  and  the  process  of  deriving  further-level  requirements  is  continued 
to  a level  of  convenience.  All  except  the  first-level  requirements  are  derived, 
rather  than  reactive. 

The  importance  of  hierarchical  levels  of  requirements  can  best  be  under- 
stood by  comparing  a second-level  requirement  with  a sixth-level  requirement. 

The  second-level  requirement  is  a far  more  important  constraint  than  the  sixth- 
level,  and  cannot  be  subjected  to  the  same  level  of  tradeoff  freedom  as  can  the 
sixth-level  requirement.  What  is  essentially  being  considered  here  is  a varying 
degree  of  "must-ness"  with  respect  to  the  requirement  levels.  The  higher  levels 
(first  and  second)  of  requirements  are  generally  quite  inflexible,  while  those  at 
the  lower  levels  can  be  treated  in  increasingly  freer  fashion  throughout  their 
application  to  alternate  approaches. 
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1.  4 LIMITATIONS 


Four  types  of  limitations  constrained  the  Task  2 effort  and  this  report.  These 
involve  schedule/cost  factors,  the  preliminary  status  of  requirements  that  are  sub- 
ject to  Navy  review,  potential  impacts  of  Task  1 report  changes,  and  flexibility  in 
User-Data  Match  requirements  which  depend  upon  an  upcoming  human  factors 
repo  rt, 

Limitations  Involving  Schedule/Cost  — Inherent  limitations  in  the  scope  of 
Task  2 are  offered  by  the  preplanned  expenditure  of  some  20  man-months  of  effort 
and  appropriate  funding  across  the  concurrent  Task  1 and  Task  2 reporting  period 
of  less  than  7 months.  (The  reporting  period  is  defined  as  commencing  with  con- 
tract award  on  24  June  1970  and  continuing  through  24  January  1977. 

User- Data  Match  Flexibility-  A major  element  in  the  User-Data  Match 
Research  Issue  is  the  human  factors  study  currently  in  progress  by  Anacapa 
Sciences,  Inc.,  of  Santa  Barbara,  California.  This  firm  is  operating  as  Hughes 
subcontractor  for  this  portion  of  the  NTIPP  effort,  and  - under  contractual  terms 
agreed-upon  by  Hughes  and  the  NTIPP  Program  Office  — will  not  submit  its  final 
human  factors  study  report  until  31  March  1977.  As  a result,  the  User-Data 
Match  requirements  have  necessarily  been  formulated  to  be  sufficiently  flexible 
to  fully  incorporate  the  findings  of  that  report. 

Firmness  of  Requirements  — The  requirements  documented  in  this  Task  2 
report  are  regarded  as  relatively  firm,  since  Navy  review  has  taken  place  and 
appropriate  additions,  deletions,  and  modifications  have  been  made  prior  to  issue 
of  the  Task  2 report  in  this  final  form.  These  agreed-upon  requirements  will  be 
used  to  constrain  the  baseline  process  in  Tasks  3,  4,  and  5.  However,  it  is  noted 
that  individual  requirements  given  herein  are  still  subject  to  change,  if  the  need 
for  such  change  is  disclosed  during  the  baseline  process,  and  if  such  change  is 
determined  to  be  in  the  best  interests  of  the  Navy. 
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1.5  PLAN  OF  REPORT 


This  Task  2 Report,  NTIPP  CDRL  A002,  conforms  to  the  requirements  of  Data  Item 
Description  UDI-S-7060.  The  body  of  the  report  is  divided  into  discussions  of  top- 
level  NTIPP  requirements,  research  issue  level  NTIPP  requirements,  and  provi- 
sions  for  obtaining  Navy  review  and  approval  of  these  requirements. 

This  document  is  the  second  of  five  end-of-task  reports  which  are  governed 
by  the  provisions  of  Data  Item  Description  (DID)  UDI-S-7060,  dated  1 July  1975, 
from  the  David  W.  Taylor  Naval  Ship  Research  and  Development  Center,  Code 
186A,  Bethesda,  Maryland.  The  above-cited  DID  specifies  the  utilization  of 
Sections  1 and  2 as  Introduction  and  Methodology,  respectively,  and  the  last 
two  Sections  (herein  6 and  7)  as  Conclusions  and  Recommendations,  respectively. 
Intervening  Sections  (herein  3,  4,  and  5)  are  to  be  utilized  for  the  body  of  the 
report.  Appendices  as  needed  are  permitted  by  the  DID. 

Section  2,  Methodology,  sets  forth  the  relationship  of  Tasks  in  the  overall 
NTIPP  effort,  and  describes  the  constraints  bounding  NTIPP  requirements  as 
well  as  techniques  for  synthesizing  such  requirements. 

Section  3 is  devoted  to  the  top-level  NTIPP  requirements,  and  covers 
both  the  rationale  and  the  description  thereof.  These  are  the  requirements  involv- 
ing NTIPP  as  a whole,  rather  than  being  specifically  addressed  to  a given 
research  issue;  the  latter  type  is  provided  in  Section  4,  Research  Issue  Level 
NTIPP  Requirements.  Section  5 is  dedicated  to  the  suggested  provisions  for 
obtaining  review  and  approval  of  the  NTIPP  requirements,  including  treatment 
of  modifications  which  arise  from  the  review  process. 

The  report  contains  two  appendices.  One  is  a list  of  references,  repre- 
senting documents  specifically  used  in  the  Task  2 effort,  and  the  other  a glos- 
sary of  abbreviations  and  acronyms  used  in  the  report. 
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2. 1 RELATIONSHIP  OF  TASK  2 TO  THE  TOTAL  NTIPP  EFFORT 


The  purpose  of  Task  2,  Establishment  of  NTIPP  Requirements,  is  to  constrain  the 
synthesis  of  preliminary  alternatives  in  Task  3 by  serving  as  a threshold  which  any 
and  all  viable  alternatives  must  satisfy  as  a condition  of  being  accepted  for 
consideration. 

Task  2 is  the  second  of  seven  tasks  in  NTIPP  Phase  I — Systems  and  Feas- 
ibility Tradeoff  Analyses  (SFTOA).  The  relationship  of  Task  2 to  the  other 
SFTOA  Tasks  is  shown  in  simplified  form  in  Figure  2-1  on  the  facing  page.  The 
principal  input  to  Task  2 is  the  information  base  produced  in  Task  1,  from  which 
a consistent  set  of  preliminary  requirements  has  been  developed.  These  require- 
ments establish  the  generalized  conduct  of  NTIPP  functions  in  part  and  in  whole, 
and  are  based  upon  rigorous  examination  of  technical  manual  systems  in  the  U.  S. 
Navy  and  other  organizations.  Engineering  judgment  was  applied  to  the  informa- 
tion base  of  Task  1,  both  to  define  areas  of  existing  adequacy  and  to  determine 
gaps  in  coverage  — i.e. , areas  not  sufficiently  accommodated  in  current  and  pro- 
posed technical  manual  systems  — which  should  be  remedied  through  the  imposi- 
tion of  future  requirements. 

The  requirements  set  forth  herein  are  the  output  of  Task  2 and  represent 
the  control  mechanism  for  assessing  the  validity  of  potential  alternatives  to  be 
synthesized  in  Task  3.  This  means  that  every  alternative  deemed  worthy  of  con- 
sideration in  Task  3 must,  at  a minimum,  satisfy  the  NTIPP  requirements  docu- 
mented in  this  report,  thereby  assuring  that  the  emerging  baseline  begins  and 
remains  within  a suitable  envelope  of  system-level  constraints  throughout  the 
balance  of  SFTOA  tasks. 

Two  bounding  considerations  guided  the  formulation  of  this  set  of  NTIPP 
requirements.  First,  the  requirements  must  be  sufficiently  definitive  to  serve 
as  a reasonable  threshold  - i.e. , they  act  to  reject  inadequate  or  infeasible 
approaches  which  might  otherwise  be  embodied  in  possible  alternatives.  Second, 
they  must  be  sufficiently  flexible  to  avoid  inadvertently  rejecting  viable  approaches 
which  were  not  foreseen  when  the  requirements  were  established.  The  proper 
balance  between  rigor  and  flexibility  is  a matter  of  engineering  judgment  which 
was  aided  by  the  concurrent  conduct  of  Tasks  1 and  2.  NTIPP  research  person- 
nel preparing  the  Task  2 requirements  are  the  same  individuals  who  performed 
the  comparative  system  analysis  in  Task  1,  and  who  will  be  responsible  for  con- 
ducting the  synthesis  and  preliminary  selection  of  NTIPP  alternatives  in  Task  3. 
Hence,  continuity  is  provided  between  the  real-world  information  base  and  the 
requirements  and  alternatives  derived  from  it. 


TASK  2 


Figure  2-1.  Relationship  of  Task  2 to  Overall  NTIPP  Effort.  Results  of  Task  1 constitute  the 
principal  information  for  conduct  cf  Tasks  2 and  3,  with  Task  2 results  serving  as  a control 
mechanism  to  screen  potential  alternatives. 
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2.2  CONSTRAINTS  BOUNDING  THE  ESTABLISHMENT  OF  PRELIMINARY  NT1PP 
REQUIREMENTS 

Examination  of  the  goals  of  N 1'IPP,  its  relationship  to  the  Weapons  System  Acquisi- 
tion Process,  and  the  strong  "people  presence"  provide  the  means  of  identifying  the 
formation  constraints. 

figure  2-2  on  the  lacing  page  relates  two  of  the  primary  constraints  facing 
NTIPP.  It  is  recognized  that  NTIPP  is  not  a weapons  system  and  that,  in  fact, 
NTIPP  may  not  be  identified  as  a "system"  even  in  its  final  form.  The  need 
remains,  however,  to  address  the  problem-set  defined  by  NTIPP  in  a "systematic 
and  ordered"  fashion.  One  can  also  recognize  the  fact  that  NTIPP  must  be  respon- 
sive to  the  Weapons  System  Acquisition  Process  which  is  characterized  by  a 
particular  version  and  applic  ation  of  system  engineering  principles  (see  MIL- 
STD-499A).  The  only  discipline  available  to  ensure  a thorough  NTIPP  design 
process  is  that  known  presently  as  systems  engineering.  This  is  not  the  military 
version,  but  its  civilian  counterpart;  however,  the  close  ties  of  NTIPP  to  the 
military  enable  ready  use  of  some  aspects  of  weapons  systems  engineering. 

The  reactive  nature  of  NTIPP  is  not  only  related  to  the  Weapons  System 
Acquisition  Process,  but  also  to  the  user.  The  user  community  represents  a 
primary  constraint,  and  this  is  the  sole  purpose  of  the  "User-Data  Match"  re- 
search issue.  There  are  other  facts  which  can  be  considered  as  constraints  to 
NTIPP  requirements  in  addition  to  those  mentioned  above.  Consider  the  need 
for  people  and  their  various  roles  in  NTIPP.  When  analyzing  the  research 
issue  structure  being  employed  as  the  management  control  to  conduct  this  re- 
search and  development,  all  of  the  issues  must  consider  people.  Perhaps  the 
Replication  and  Distribution  issues  have  the  smallest  "people"  impact;  however, 
no  one  has  discovered  how  to  accomplish  even  these  functions  without  people. 

This  "people"  constraint  sets  the  NTIPP  function  a considerable  distance  apart 
from  those  normally  considered  in  weapons  system  engineering,  where  "people" 
interfaces  are  generally  far  more  limited.  In  point  of  fact,  the  output  products 
of  NTIPP  must  be  "matched"  to  certain  classes  of  people  (user  community)  and 
this  transform  must  be  accomplished  by  people  (content  generator  — technical 
writers).  Human  engineering  has  addressed  the  "man-machine"  interface  in 
the  weapons  system  world  in  considerable  depth,  while  very  little  applied  re- 
search was  undertaken  in  the  "man-data"  interface. 

A formative  constraint  on  NTIPP  lies  in  the  content  and  structure  of  the 
engineering  data  base  which  is  transformed  by  the  content  generator  into 
"matched"  MOTD.  It  is  logical  to  postulate  that  some  MOTD  influence  can  be 
effected  on  this  data  base;  however,  the  realities  of  life  strongly  suggest  that  this 
influence  will  be  minimal.  On  the  whole,  the  engineering  data  base  is  considered 
a primary  constraint  in  the  NTIPP  design  effort.  The  final  primary  constraint 
on  NTIPP  design  is  that  the  baseline  must  be  constructed  such  that  its  structure 
can  be  readily  accepted  by  the  current  Navy  TM  organizations.  In  other  words, 
the  transition  from  the  "current  Navy  TM  System"  to  the  successful  baseline 
developed  by  NTIPP  should  not  involve  a complex  transform.  It  can  be  argued 
that  this  is  part  and  parcel  of  the  "people"  constraint  cited  earlier,  but  it  is 
felt  that  this  condition  is  of  sufficient  significance  that  it  warrants  special  con- 
sideration as  a constraint  in  its  own  right. 

A number  of  other  conditions  could  also  be  considered  as  constraints  — 
budgets,  contractor  interfaces,  types  of  manpower  levels,  etc.  The  current 
position  is  that  these  conditions  (or  items)  should  not  be  considered  as  formative 
constraints  in  baseline  development.  The  better  choice  appears  to  be  that 
these  conditions  will  be  most  effectively  treated  in  the  Performance  and  Cost 
Tradeoffs  of  Tasks  4 and  5 subsequent  to  the  preliminary  baseline  and  alternative 
design  process  of  Task  3. 
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Figure  2-2.  Constraints  on  NTIPP  Requirements.  Of  the  five  formation 
constraints  that  bound  the  development  of  NTIPP  requirements,  the  most 
important  are  those  characterized  by  “people”. 
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3.  1 RATIONALE  FOR  THE  DEVELOPMENT  OF  NTIPP  REQUIREMENTS  IN  THE 
CONCEPT  FORMULATION  PHASE  OF  THE  WEAPON  SYSTEM  ACQUISITION 
PROCESS 

NTIPP  requirements  derived  from  the  Concept  Formulation  Phase  of  the  Weapon 
System  Acquisition  process  are  the  result  of  reactions  to  the  occurrence  of  specific 
events.  Reactions  to  these  events,  in  the  form  of  requirements,  concepts  and  plans, 
form  the  basis  from  which  all  further  MOTD  development  is  initiated. 

The  Concept  Formulation  Phase  begins  with  the  determination  of  an  oper- 
ational need  or  capability.  It  is  typified  by  the  formulation  of  system  hardware 
design  and  support  concepts  which  specify  alternative  approaches  to  meeting  the 
operational  requirements  of  a proposed  system.  Figure  3-1  depicts  the  flow  of 
activity  within  the  Weapon  System  Acquisition  Process  (WSAP)  during  this  phase, 
and  notes  specific  events  which  this  research  has  found  to  be  critical  to  the 
development  of  MOTD.  NTIPP  requirements  discussed  in  this  topic  are  generated 
as  a result  of  activities  occurring  in  these  events.  For  illustrative  purposes, 
Concept  Formulation  is  shown  as  three  distinct  flows  of  activity  denoting  hard- 
ware system-level  development,  Integrated  Logistic  Support  level  development, 
and  MOTD  level  development.  In  reality,  these  flows  are  intermeshed  into  a 
complex  of  interactive,  interdependent  activities.  Regardless  of  the  manner  of 
illustrating  this  flow,  one  point  must  be  made  clear:  the  MOTD  acquisition 
activity  is  driven  by,  and  dependent  on,  activities  generated  at  the  system 
design  level  of  the  process  through  ILS.  It  is  not  a "stand-alone"  activity;  it  is 
always  reacting  to  system  user  needs. 

The  first  event  in  this  phase  is  the  statement  of  an  operational  require- 
ment or  need.  This  results  in  activity  at  all  three  levels  of  the  process.  The 
preliminary  requirement  of  system  design  and  support  are  defined  from  analysis 
of  the  stated  operational  capability  or  need.  NTIPP  requirements  resulting  from 
this  event  are  based  on  the  need  to  define  preliminary  MOTD. 

One  may  ask  why  it  is  necessary  to  get  involved  with  MOTD  at  such  an 
early  stage  of  system  development.  It  is  at  this  time  that  the  fundamental  ques- 
tions of  proposed  system  design  should  be  addressed:  system  complexity,  oper- 
ating environment,  user  skill  requirements,  maintenance  philosophy,  etc.  The 
answer  to  these  and  many  other  such  basic  questions  result  in  the  formulation  of 
preliminary  system  and  support  requirements.  MOTD  requirements  must  be 
based  on  a thorough  analysis  of  proposed  system  characteristics,  not  just  a sim- 
ple correlation  of  current  MOTD  capabilities  to  apparent  system  needs.  Such  an 
analysis  requires  that  the  various  characteristics  of  the  proposed  system  design 
be  matched  to  the  needs  of  proposed  equipment  users  and  impacted  by  other  re- 
lated support  activities.  The  place  for  this  User/Data  Match  to  take  place  is 
"up-front"  in  the  acquisition  process  where  the  greatest  impact  on  overall  system 
and  support  design  can  be  felt. 

The  next  event  in  this  phase  results  in  the  formulation  of  an  MOTD 
concept.  Again,  for  the  purposes  of  illustration,  it  has  been  depicted  as  begin- 
ning the  analysis  of  MOTD  capabilities. 

Based  on  the  results  of  the  required  capability  analysis,  current  techno- 
logical capabilities  are  examined  to  see  if  they  can  fulfill  the  preliminary  MOTD 
. requirements.  Normally,  several  approaches  are  prepared  and  tradeoffs  are 

conducted  to  determine  which  ones  fall  within  acceptable  bounds.  This  set  of 
tradeoffs  may  involve  an  advanced  development  model  or  models  to  test  the 
feasibility  of  proposed  approaches,  which  include  technology  not  currently  uti- 
* lized.  The  end  result  is  the  formulation  of  an  MOTD  development  concept  which 

reflects  those  approaches  considered  feasible  for  further  development.  This 
t MOTD  concept  becomes  a part  of  the  ILS  concept,  which  in  turn  is  a part  of  the 


the  overall  system  design  concept.  It  should  be  evident  that  the  requirements 
developed  "up-front"  are  now  an  integral  part  of  the  overall  system  design. 

The  last  event  of  this  phase  is  the  establishment  of  a MOTD  development 
plan.  It  is  here  that  schedules  are  established  and  coordinated  with  system  devel- 
opment. These  schedules,  together  with  the  concepts  developed  in  the  previous 
event,  become  part  of  the  overall  systems  development  plan.  Obviously,  proper 
planning  of  MOTD  development  is  mandatory  if  user  data  is  to  be  produced  and 
deployed  concurrently  with  the  equipment.  The  Systems  Development  Plan  is 
reviewed  and  subjected  to  approval  by  DSARC  I before  the  acquisition  process 
can  proceed  to  the  next  phase. 

The  primary  intent  of  the  NTIPP  requirements  established  for  this  phase 
is  to  insure  that  MOTD  considerations  become  an  integral  part  of  the  early  sys- 
tem design  process.  For  that  reason,  MOTD  acquisition  activity  must  be  reac- 
tive in  nature  and  its  detailed  operational  requirements  structured  in  such  a 
manner  as  to  consider  the  interactive  elements  of  the  proposed  system  as  an 
integral  part  of  the  user  data  design  process. 
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Figure  3-1.  Comparison  of  the  Weapon  System  Acquisition  Process  and  Resultant  Actions  in  the  ILS 
and  MOTD  Realms.  Insufficient  Attention  is  currently  paid  to  defining  MOTD  factors  during  the 
early  portion  of  the  Concept  Formulation  Phase. 
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3.  2 REQUIRED  NTIPP  ACTIONS  DURING  WEAPONS  SYSTEM  CONCEPT  FORMULATION 


During  Concept  Formulation,  MOTD  acquisition  must  be  addressed  in  a manner 
analagous  to  that  used  for  hardware  acquisition  — a comprehensive  systems  engi- 
neering approach.  A MOTD  Acquisition  Manager's  Handbook  is  needed  which  details 
the  methodology  to  be  used  during  the  sequence  of  events  leading  to  the  selection  of 
amumber  of  viable  MOTD  concepts  for  supporting  the  proposed  system. 

The  first  MOTD-related  event  during  concept  formulation  is  the  definition 
of  MOTD  requirements  with  respect  to  the  operational  and  support  capability  of 
the  proposed  system.  Formulation  of  general  MOTD  requirements  is  based  up- 
on analysis  of  the  following  preliminary  data:  (1)  System  complexity  to  a func- 
tional level;  (2)  System  maintainability  characteristics  such  as  the  existence  of 
built-in  test  equipment  (BITE),  automatic  test  equipment  (ATE),  and  computer 
diagnostics;  (3)  User  characteristics  such  as  personnel  manning  levels,  skill 
levels,  and  skill  specialities;  (4)  Environmental  characteristics  such  as  work 
space,  wind,  noise,  and  dirt;  (5)  Maintenance  task  characteristics  such  as  type, 
criticality,  complexity,  and  frequency;  (7)  Current  and  proposed  MOTD  presen- 
tation media  such  as  paper,  microform,  and  video  disc;  (8)  Current  and  proposed 
MOTD  presentation  techniques  such  as  JPA,  FOMM,  ;ind  Work  Package;  (9)  Num- 
ber of  systems  to  be  developed,  and  (10)  MOTD  interfaces  with  the  training 
community. 

The  second  MOTD-related  event  during  concept  formulation  is  the  estab- 
lishment of  candidate  MOTD  concepts.  The  preliminary  concepts  are  detailed 
in  the  following  manner:  (1)  Develop  publications  tree,  (2)  Perform  Head/Data/ 
training  Tradeoff,  (3)  Perform  User-Data  Match,  (4)  Define  readability/ 
comprehensibility  requirements  for  text  and  graphics,  (5)  Define  presentation 
medias  (6)  Define  distribution  methodology,  (7)  Define  validation/verification 
parameters,  (8)  Define  update  methodology,  and  (9)  Define  feedback  origins  and 
methodology. 

The  third  MOTD-related  event  during  concept  formulation  is  the  selection 
of  viable  MOTD  concepts  for  consideration  during  the  validation  phase.  Selec- 
tion of  viable  alternatives  from  the  various  candidate  MOTD  concepts  is  accom- 
plished through  the  performance  of  gross  cost/ effectiveness  analysis.  In  this 
manner,  candidate  MOTD  concepts  which  are  deemed  unaffordable,  or  fall  out- 
side the  bounds  of  the  existing  support  capability,  are  eliminated  from  further 
consideration. 

The  fourth  and  final  MOTD-related  event  during  concept  formulation  is 
the  development  of  preliminary  plans  for  implementation  of  the  selected  MOTD 
approaches.  These  preliminary  plans  consist  of  establishing  schedules  for  items 
such  as  review  of  publication  planning  documents,  in-process  reviews,  draft 
MOTD  completion,  validation/verification,  final  MOTD  delivery,  and  update 
cycles.  The  impact  of  non-compliance  with  the  key  elements  of  the  MOTD  plan 
must  be  defined  so  the  Program  Manager  can  make  system  tradeoffs  effectively. 
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TABLE  3-1.  NTIPP  REQUIREMENTS  INVOLVING  THE  CONCEPT  FORMULATION  PHASE 


Reactive  Requirements 


• Define  MOTD  requirements  with 
respect  to  the  operational 
and  support  capability  of 
proposed  system 


Derived  Requirements 


• Formulate  general  MOTD  requirements  to 
support  proposed  system  based  on: 

— System  complexity 
— System  maintainability  characteristics 
— User  characteristics 
— Environmental  characteristics 
— Maintenance  philosophy 
- Maintenance  task  characteristics 
— MOTD  presentation  media 
— MOTD  presentation  techniques 
— Number  of  systems 
— Training  interface 


• Establish  candidate  MOTD 
concepts  derived  from  analysis 
of  general  MOTD  requirements 


• Select  viable  MOTD  concepts 
for  consideration  during 
validation  phase 


• Formulate  MOTD  guidance  concepts  as  follows: 
— Develop  publications  tree 

- Perform  Head/Data/Training  Trade-off 

- Perform  User-Data  Match 

— Define  readability/ comprehensibility 
requirements  for  text  and  graphics 
— Define  presentation  medias 
— Define  distribution  methodology 
— Define  validation/verification  parameters 

- Define  update  methodology 

— Define  feedback  origins  and  methodology 

• Perform  gross  cost/effectiveness  analysis 
bounded  by  affordability  and  capabilities  of 
existing  support  system  — call  out  applicable 
specification  modules 


• Develop  planning  necessary  to 
implement  MOTD  concepts  for 
proposed  system 


• Formulate  plan  for  development  and  produc- 
tion of  MOTD  concepts  as  follows: 

— Schedule  review  of  publication  planning 
documents 

— Schedule  in-process  reviews 
— Schedule  draft  MOTD  completion 
— Schedule  validation/verification 
— Schedule  final  MOTD  delivery 
— Schedule  update  cycles 
- Impact  of  non-compliance 
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3.  3 RATIONALE  FOR  DEVELOPMENT  OF  NTIPP  REQUIREMENTS  IN  THE 
VALIDATION  PHASE  OF  THE  WEAPON  SYSTEM  ACQUISITION  PROCESS 

The  primary  objective  of  the  Validation  Phase  is  to  select  a design  and  support 
approach  for  development  of  a proposed  system  through  study,  analysis,  and  trade- 
off. NTIPP  requirements  established  for  this  phase  provide  guidelines  for  develop- 
ment of  specific  MOTD  requirements,  and  formulation  of  criteria  for  assessment 
of  contractor  proposal  and  responses. 

The  second  phase  of  the  Weapon  System  Acquisition  Process  is  Validation. 
Concepts  and  plans  developed  in  the  previous  phase  are  validated  and  refined 
through  extensive  study,  analysis,  development  and  prototype  testing.  The 
primary  objective  is  to  select,  from  the  group  of  alternatives  developed  in  the 
Concept  Formulation  Phase,  one  approach  which  meets  the  overall  system  design 
requirements  while  maintaining  cost  as  an  equal  parameter  with  performance 
and  schedule.  NTIPP  requirements  are  derived  from  an  inherent  need  to  react 
to  the  Weapon  System  Acquisition  Process.  The  flow  of  activity  within  this  proc- 
ess is  depicted  in  Figure  3-2.  For  the  purpose  of  this  discussion,  it  has  been 
shown  as  occurring  on  three  distinct  levels:  system  design/development,  Inte- 
grated Logistic  Support  development,  and  Maintenance  and  Operation  Technical 
Data  development,  with  specific  events  occurring  phased  sequence  between 
them.  In  reality,  this  activity  is  a complex  of  intermeshed,  interdependent  ac- 
tions with  events  overlapping  each  other.  The  events  noted  here  are  not  to  be 
considered  as  all  of  those  which  take  place,  or  are  likely  to  take  place,  but 
only  those  which  this  research  has  found  to  be  most  critical. 

The  Validation  Phase  begins  with  the  approval  of  the  systems  development 
plan  established  in  Concept  Formulation.  This  approval  initiates  activity  at  the 
system  development  level  to  establish  design  and  support  requirements  from  the 
basic  concepts  developed  in  the  previous  phase.  Such  activity  at  the  systems 
level  requires  a reaction  at  the  MOTD  development  level.  As  such,  NTIPP  begins 
the  development  of  MOTD  requirements.  These  requirements  define  parameters 
and  specifications  to  be  used  for  further  development  of  the  MOTD  concept  estab- 
lished in  Concept  Formulation.  Included  in  these  would  be  preliminary  technical 
requirements  by  type  and  location,  specifications  for  use  of  existing  data,  speci- 
fication for  development  of  new  data,  constraints  upon  development  and  use  of 
data  and  program  milestones.  But  to  achieve  any  appreciable  level  of  confidence 
in  these  requirements,  the  publications  tree,  head/ data/training  tradeoff/user- 
data  match,  validation/verification  parameters,  etc.  , must  be  validated  against 
the  latest  system  design  information  available.  In  this  way  any  design  changes 
or  improvements  incorporated  after  the  establishment  of  the  basic  system  sup- 
port concept  will  be  taken  into  account  when  MOTD  requirements  are  developed. 

As  these  requirements  normally  become  part  of  the  input  to  an  RFP, 
some  criteria  for  evaluating  a contractor's  response  to  them  must  also  be  estab- 
lished. These  criteria  are  utilized  to  assess  the  contractor's  logic  for  use  of  an 
existing  presentation  technique  or  development  of  new  ones,  and  the  validity  of 
his  costs  and  proposed  methods  for  demonstrating  the  use  of  MOTD  to  support 
operations,  training,  and  maintenance.  It  is  also  at  this  time  that  the  method 
of  proposal  approach  is  established.  The  selection  of  an  approach  is  dependent 
upon  whether  the  MOTD  requirements  can  be  addressed  adequately  by  the  nor- 
mal "paper  competition"  methods  of  response,  i.  e. , written  proposals  with 
appropriate  backup,  or  whether  they  must  be  addressed  through  an  actual  demon- 
stration of  a design  concept,  such  as  prototype.  The  primary  reason  for  includ- 
ing criteria  as  a requirement  of  NTIPP  is  to  assure  that  a means  is  developed 
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which  aids  in  the  determination  of  the  feasibility  of  new  concepts  or  techniques, 
and  can  point  out  potential  problem  areas  before  they  become  so  severe  as  to 
cause  significant  modification  of  requirements  later  in  MOTD  acquisition. 

For  the  purpose  of  this  discussion,  it  can  now  be  assumed  that  an  RFP 
has  been  ieleased  and  responses  have  been  received.  Perhaps  the  most  impor- 
tant event  of  this  phase  now  takes  place.  Contractor  responses  are  analyzed 
and  tradeoff  evaluations  made  against  the  previously  established  criteria  for 
selection  of  an  approach  which  best  meets  the  requirements  of  MOTD  develop- 
ment and  system  support.  Again,  the  various  elements  of  MOTD  development 
are  addressed:  publication  tree  coverage,  validation/verification  plans,  com- 
pliance with  user-data  match  parameters,  cost  estimations,  criteria  manage- 
ment, planning  and  control,  etc.  Obviously,  NTIPP  requirements  for  this  trade- 
off are  a restatement  of  the  assessment  criteria  with  emphasis  placed  on  "the 
degree”  to  which  a particular  approach  satisfies  the  MOTD  requirements.  As 
decisions  are  reached  regarding  these  trade-offs,  they  become  a part  of  the 
overall  system  design  and  support  approach  which  is  then  subjected  to  review 
and  approval  by  DSARC  II,  before  proceeding  to  the  next  phase. 

The  basic  approach  behind  the  establishment  of  NTIPP  requirements 
during  the  Validation  Phase  is  to  assure  that  MOTD  concepts  developed  in  the 
previous  phase  are  reactive  to  the  dynamic  nature  of  the  Weapon  System  Acqui- 
sition Process.  The  developmental  process  of  system  design  demands  changes 
in  concept;  hence,  NTIPP  must  have  the  capacity  to  continually  reassess  its 
development  approach  and  design  efforts.  The  establishment  of  MOTD  require- 
ments and  assessment  criteria  to  a detail  level  leads  to  better  trade-off  and 
assessment  techniques. 
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Figure  3-2.  Relationship  of  MOTD  Events  to  WSAP  Actions  in  the  Validation  Phase.  Detailed 
planning  is  required  to  establish  MOTD  requirements  in  sufficient  depth  to  support  MOTD  pro- 
curements from  contractors. 
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3.4  REQUIRED  NTIPP  ACTIONS  DURING  WEAPONS  SYSTEM  VALIDATION  PHASE 


The  purposes  of  validation  are  to  verify  preliminary  MOTD  design  concepts, 
accomplish  necessary  planning,  resolve  or  minimize  developmental  risks  identified 
during  concept  formulation,  and  prepare  the  formal  requirement  documents  that  are 
the  basis  for  full-scale  development. 

The  initial  MOTD- related  event  during  validation  is  the  development  of 
formal  MOTD  requirements  which  meet  the  proposed  system  support  concept  (see 
Table  3-11).  To  establish  specific  MOTD  development  requirements  for  support 
of  the  proposed  system,  the  preliminary  data  used  to  formulate  the  general 
MOTD  requirements  must  be  validated.  This  data  which  was  analyzed  in  concept 
formulation  is  detailed  in  Topic  3.2.  Based  upon  changes  in  items  such  as  sys- 
tem hardware  and  maintainability  characteristics  uncovered  during  this  data  vali- 
dation, the  MOTD  guidance  concepts  are  modified  and  finalized.  These  guidance 
concepts,  which  were  established  during  concept  formulation,  are  also  discussed 
in  Topic  3.2.  The  final  task  to  be  performed  during  this  event  is  the  selection 
of  a family  of  specifications  which  are  compatible  with  the  MOTD  requirements. 

The  next  MOTD- related  event  during  validation  is  the  establishment  of 
criteria  for  assessing  compliance  with  MOTD  development  requirements.  To 
define  criteria  for  evaluation  of  proposed  approaches  with  respect  to  meeting 
MOTD  requirements,  the  following  steps  must  be  taken:  (1)  Assess  risks, 

(2)  Establish  risk  boundaries,  (3)  Establish  MOTD  test  parameters,  (4)  Establish 
validation/verification  parameters,  and  (5)  Prepare  MOTD  input  to  the  RFP. 

Risk  assessment  is  the  subjective  determination  that  a specific  perform- 
ance, schedule,  or  cost  objective  will  or  will  not  be  attained  with  the  planned 
course  of  action.  Risk  analysis  and  the  establishment  of  acceptable  risk  boun- 
daries are  necessary  for  determining  the  reasonableness  and  acceptability  of 
proposed  MOTD  approaches.  During  Validation,  the  elements  of  risk  which  con- 
stitute the  most  critical  uncertainties  in  Full-Scale  Development  are  identified. 
Many  factors  impacting  MOTD  performance,  cost,  and  schedule  cannot  be  fore- 
cast with  adequate  confidence  merely  through  paper  designs  and  analytical  stud- 
ies. For  example,  the  ability  of  a particular  MOTD  concept  to  meet  hardware 
mean-time-to-repai r requirements  and  data  access  time  requirements  is  seldom, 
if  ever,  certain  until  after  the  hardware  and  MOTD  have  actually  been  built  and 
tested. 

Test  parameters  must  be  established  to  evaluate  MOTD  adherence  to 
requirements  such  as  those  related  to  user-data  match,  training  and  maintenance 
philosophy.  Finally,  the  MOTD  input  to  the  RFP  is  prepared,  detailing  the  spe- 
cific MOTD  development  requirements,  the  finalized  MOTD  guidance  concepts 
and  the  selected  family  of  MOTD  specifications. 

The  final  MOTD- related  event  during  validation  is  the  evaluation  of  pro- 
posed approaches  for  adherence  to  MOTD  requirements  based  on  the  established 
criteria.  The  various  contractor  MOTD  proposals  are  traded  off  based  upon  the 
following  considerations:  (1)  Publications  tree  coverage,  (2)  Validation/ 
verification  plan  coverage,  (3)  Compliance  with  user-data  match,  training,  and 
maintenance  philosophy  requirements,  (4)  Recognition  of  impact  of  other  related 
support  elements,  (5)  Management  risks,  (6)  Cost,  (7)  Cost  control,  and  (8)  Cost 
collection.  Recommendations  are  then  prepared,  and  submitted  to  the  Program 
Acquisition  Management  office  for  consideration  during  the  contract  award  process. 
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TABLE  3 —II.  REQUIREMENTS  INVOLVING  THE  VALIDATION  PHASE 


Reactive  Requirements 

Derived  Requirements 

• Develop  formal  MOTD  requirements 
which  meet  proposed  system  support 
concept 

• Establish  specific  MOTD  development 
requirements  for  support  of  proposed 
system  as  follows: 

- Validate  preliminary  data  used  to 
formulate  general  MOTD  requirements 

— Finalize  MOTD  guidance  concepts 

- Select  family  of  MOTD  specifications 

• Establish  criteria  for  assessing 
compliance  with  MOTD  development 
requirements 

• Define  criteria  for  evaluation  of  proposed 
approaches  with  respect  to  meeting  MOTD 
requirements  as  follows: 

— Assess  risks 

- Establish  risk  boundaries 

- Establish  MOTD  test  parameters 
— Establish  validation/verification 

parameters 

- Prepare  MOTD  input  to  RFP 

• Evaluate  proposed  approaches  for 
adherence  to  MOTD  requirements 
based  on  established  criteria 

• Perform  trade-off  analysis  of  MOTD 
proposals  based  on: 

— Publications  tree  coverage 
— Validation/Verification  plan  coverage 
- Compliance  with  User-Data  Match, 
training,  and  maintenance  philosophy 
requirements 

— Recognition  of  impact  of  other  related 
support  elements 
— Management  risks 
— Cost 

— Cost  control 
— Cost  collection 
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3.  5 RATIONALE  FOR  THE  DEVELOPMENT  OF  NTIPP  REQUIREMENTS  IN  THE 
THE  FULL-SCALE  DEVELOPMENT  PHASE  OF  THE  WEAPON  SYSTEM 
ACQUISITION  PROCESS 

During  the  Full-Scale  Development  Phase  of  the  Weapon  System  Acquisition  Process, 
the  system  (including  its  supporting  elements)  are  fabricated  and  tested.  NTIPP 
requirements  resulting  from  this  phase  are  essentially  those  which  serve  to  insure 
that  MOTD  is  produced  according  to  predefined  concepts  and  plans. 

The  Full-Scale  Development  Phase  of  the  Weapon  System  Acquisition 
Process  begins  with  the  approval  of  a design  approach  and  award  of  a development 
contract.  It  is  during  this  phase  that  the  system,  including  all  of  its  supporting 
elements,  is  designed,  fabricated,  and  tested.  The  intended  output  is,  as  a 
minimum,  a preproduction  system  which  closely  approximates  the  final  product, 
the  documentation  necessary  to  enter  the  production  phase,  and  test  results  which 
meet  the  system  design  and  support  requirements.  Figure  3-3  depicts  the  flow 
of  activity  during  full-scale  development,  with  specific  events  noted  which  this 
research  has  found  to  be  critical  to  the  process  of  acquiring  MOTD.  As  stated 
previously  in  Topics  3.  1 and  3.  3,  this  flow  has  been  shown  as  three  separate 
activities  for  illustrative  purposes  only. 

The  first  event  to  occur  which  is  of  significance  to  the  establishment  of 
NTIPP  requirements  is  the  preparation  of  a detail  plan  by  a selected  contractor 
for  development  of  preliminary  MOTD.  This  requires  the  establishment  of  an 
interface  with  the  contractor,  to  review  and  assess  his  plans  for  compliance  with 
the  stated  design  and  development  MOTD  approach.  Such  review  and  assessment 
activity  at  this  point  requires  that  a determination  be  made  of  the  inherent  risks 
in  a contractor's  plans  and  schedules,  his  ability  to  maintain  costs  within  estab- 
lished bounds,  the  completeness  of  his  publications  tree  coverage,  his  compliance 
with  established  user-data  match  criteria,  consideration  of  other  related  support 
activities  such  as  training,  spares,  maintenance,  etc.  , in  his  plans,  validation/ 
verification  considerations,  and  planned  activity  for  updating  MOTD  as  a result 
of  design  change.  By  assuring  that  a contractor's  preliminary  MOTD  develop- 
ment plans  accurately  reflect  the  design  concept,  errors  which  could  result  in 
costly  subsequent  change  can  be  corrected  before  they  become  a major  problem. 

At  this  juncture,  the  contractor  will  begin  preparation  of  the  preliminary 
MOTD.  NTIPP  requirements  during  this  event  will  concern  the  conduct  of  in- 
process  reviews,  to  assure  compliance  with  established  plans  and  schedules  and 
to  assess  the  compatibility  of  what  is  being  produced  with  respect  to  the  evolving 
system  design  and  support  concept.  The  specific  requirements  of  an  in-process 
review  concern  the  assessment  of  such  items  as  variance  from  established  plans 
and  schedules,  risks  incurred  and  anticipated,  costs  incurred  and  projected, 
actual  impact  of  other  related  support  activities  on  the  MOTD  being  produced, 
and  actual  compliance  with  user/data  match  criteria.  The  rationale  for  estab- 
lishment of  these  requirements  as  part  of  an  in-process  review  activity  is  to 
assure  that  MOTD  preparation  is  proceeding  according  to  plan. 

The  last  event  of  this  phase  is  to  receive  the  preliminary  MOTD  and  ver- 
ify its  suitability.  It  must  be  prepared  in  accordance  with  the  approved  plans 
and  provide  for  validation  during  system  and  support  demonstration.  NTIPP 
requirements  must  confirm  that  the  MOTD  format  and  content  matches  the  cur- 
rent design  configuration  and  satisfies  support  requirements  and  goals  estab- 
lished in  previous  analysis.  Compatibility  of  MOTD  with  equipment  configuration 
is  a prerequisite  to  establishment  of  a product  baseline  and  approval  to  proceed 
to  the  next  phase. 


Figure  3-3.  Relationship  of  MOTD  to  Systems  Development  in  the  Full-Scale  Development  Phase  of 
the  WSAP.  NTIPP  requirements  developed  for  this  phase  are  designed  to  insure  that  preliminary  MOTD 
is  developed  and  produced  in  accordance  with  established  concepts. 


Section  3 — Top-Level  NTIPP  Requirements 


3.  6 REQUIRED  NTIPP  ACTIONS  DURING  WEAPON  SYSTEM  FULL-SCALE 
DEVELOPMENT 

During  Full-Scale  Development,  a continuous  interaction  exists  between  contractor 
and  government  personnel  responsible  for  MOTD  development.  This  interaction  is 
accomplished  through  logistic  and  publication  review  teams  which  provide  guidance 
to  the  contractor,  and  assist  in  resolving  problems  so  that  a totally  integrated  sup- 
port package  is  developed  according  to  schedule. 

The  initial  MOTD- related  event  during  the  Full-Scale  Development  Phase 
occurs  immediately  after  contract  award.  An  interface  is  established  with  the 
selected  contractor  to  provide  guidance  and  insure  compliance  with  the  stated 
MOTD  concept.  The  contractors  MOTD  development  plans  and  schedules  are 
reviewed  and  assessed  on  the  basis  of  the  following  characteristics:  (1)  Accept- 
ability of  inherent  risks,  (2)  Ability  to  maintain  costs  within  established  bounds, 
(3)  Completeness  of  publication-tree  coverage,  (4)  Ability  to  identify  and  develop 
additional  equipment  manuals  as  needed,  (5)  Compliance  with  established  user- 
data  match,  training,  and  maintenance  philosophy  criteria,  (6)  Consideration  of 
impact  of  other  support  activities,  and  (7)  Validation/verification  considerations. 
Additionally,  guidelines  for  desired  flexibility  in  the  design  and  development  of 
MOTD  must  be  established.  As  program-unique  characteristics  create  pre- 
viously unforeseen  data  communication  problems  which  are  not  solvable  using 
conventional  presentation  techniques,  the  contractor  is  expected  to  devise  alter- 
native MOTD  approaches  which  address  these  problems.  Procedures  must  be 
defined  for  contractor  submission  of  innovative  MOTD  concepts  to  cognizant 
government  program  personnel  for  review  and  approval. 

The  next  MOTD- related  event  during  Full-Scale  Development  is  the  con- 
duct of  in-process  reviews  to  insure  contractor  compliance  with  established  plans 
and  schedules,  and  to  assess  compatibility  with  overall  system  development. 
Contractor  MOTD  development  progress  to  date  is  reviewed  based  on  the  follow- 
ing parameters:  (1)  Variance  from  established  plans  and  schedules,  (2)  Risks 
incurred  and  anticipated,  (3)  Costs  incurred  and  anticipated,  (4)  Actual  MOTD 
compliance  with  User-Data  Match,  training,  and  maintenance  philosophy  criteria, 

(5)  Actual  impact  of  other  related  support  elements  on  MOTD  development,  and 

(6)  Acceptability  of  cost  and  schedule  reporting.  A prime  objective  of  the  in- 
process  reviews  is  to  identify  inadequacies  in  the  MOTD  being  developed  by  the 
contractor,  and  implement  corrective  measures  before  the  product  is  complete 
and  all  funds  have  been  expended. 

The  final  MOTD- related  event  during  Full-Scale  Development  is  a review 
of  completed  preliminary  MOTD  to  verify  compliance  with  requirements.  The 
preliminary  MOTD  is  assessed  with  respect  to  the  following  criteria:  (1)  Com- 
pliance with  stated  requirements,  (2)  Variance  of  risks  from  prescribed  bounds, 
(3)  Cost  variance,  (4)  Schedule  variance,  (5)  Variance  from  user-data  match, 
training,  and  maintenance  philosophy  criteria,  (6)  Variance  from  planned  impact 
ot  other  related  suggested  activities,  (7)  Compliance  with  validation/verification 
criteria,  and  (8)  Plans  and  schedules  for  user  feedback  and  update.  A critical 
aspect  of  this  review  is  to  determine  the  adequacy  of  the  plans  and  schedules  for 
updating  the  MOTD.  Deficiencies  which  are  attributable  either  to  hardware  mod- 
ifications or  to  user  comments  must  be  corrected  in  a timely  manner,  or  MOTD 
field  effectiveness  is  significantly  decreased. 
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TABLE  3 —III.  REQUIREMENTS  INVOLVING  THE  FULL-SCALE  DEVELOPMENT  PHASE 


Reactive  Requirements 

Derived  Requirements 

• Establish  interface  with  selected  con- 
tractor to  provide  guidance  and  insure 
compliance  with  stated  MOTD  concept 

• Review  and  assess  contractor  plans  and 

schedules  for  the  following: 

— Inherent  risk  in  plans  and  schedules 

- Maintaining  costs  within  established 
bounds 

- Completeness  of  publications  tree 
coverage 

- Identification  and  development  of  addi- 
tional equipment  manuals 

- Compliance  with  established  User- Data 
Match,  training,  maintenance  philosophy 
criteria 

- Consideration  of  impact  of  other  related 
support  activities 

— Validation/verification  considerations 

• Conduct  in-process  reviews  to  insure 
contractor  compliance  with  established 
plans  and  schedules,  and  to  assess 
compatibility  with  overall  system 
development 

• Review  and  assess  the  following: 

— Variance  from  established  plans  and 
schedules 

- Risks  incurred  and  anticipated 

- Costs  incurred  and  anticipated 

- Actual  compliance  with  User-Data 
Match,  training,  and  maintenance 
philosophy  criteria 

- Actual  impact  of  other  related  support 
elements  on  MOTD  development 

— Cost  and  schedule  reporting 

• Review  preliminary  MOTD  and  verify 
compliance  with  requirements 

• Assess  preliminary  MOTD  with  respect 

to  the  following: 

- Compliance  with  stated  requirements 

- Variance  of  risks  from  prescribed 
bounds 

- Cost  variance 

— Schedule  variance 

— Variance  from  User-Data  Match,  train- 
ing, and  maintenance  philosophy 
criteria 

- Variance  from  planned  impact  of  other 
related  support  activities 

— Compliance  with  validation/verification 
criteria 

- Plans  and  schedules  for  user  feedback 
and  update 
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3.7  RATIONALE  FOR  THE  DEVELOPMENT  OF  NTIPP  REQUIREMENTS  IN  THE 
PRODUCTION/DEPLOYMENT/ SUPPORT  PHASES  OF  THE  WEAPON  SYSTEM 
ACQUISITION  PROCESS 

NTIPP  requirements  generated  from  the  Production/Deployment  and  Support  phases 
of  the  Weapon  System  Acquisition  Process  result  from  the  need  to  monitor,  coor- 
dinate, and  assess  the  development  of  final  MOTD. 

Production,  Deployment  and  Support  are  the  final  phases  in  the  Weapon 
System  Acquisition  Process.  It  is  during  these  phases  that  the  system,  including 
its  training  equipment,  spares,  facilities,  maintenance  and  operator  technical 
data,  etc.,  are  produced  for  operational  use.  The  primary  objective  is  to 
deliver  to  the  operational  unit(s)  an  effective,  supportable  system  at  an  optimum 
cost.  NTIPP  requirements  resulting  from  these  phases  are  normally  directed 
toward  monitoring,  controlling,  and  assessing  the  production,  deployment  and 
support  of  MOTD  against  concepts,  plans,  and  criteria  developed  in  the  pre- 
vious phases.  As  in  topics  3.1,  3.3,  and  3.5,  the  flow  of  activity  within  these 
phases  of  the  Weapon  System  Acquisition  Process  is  illustrated  in  Figure  3-4 
as  occurring  at  three  separate  levels. 

Production  begins  with  the  order  to  procure  formal  technical  documenta- 
tion. This  order  is  based  on  the  proposed  product  baseline  established  during 
the  previous  phase  of  the  acquisition  process  and  approval  to  award  support 
resources  contracts.  NTIPP  requirements  resulting  from  this  activity  center 
on  assuring  that  the  plans  and  schedules  for  procurement  of  formal  MOTD 
accurately  reflect  the  production  baseline  design  and  support  critieria.  Signi- 
ficant elements  of  this  requirement  are  acceptability  of  anticipated  risk, 
completeness  of  publications  tree  coverage,  compliance  with  user/data  match, 
training  and  maintenance  philosophy  criteria,  and  considerations  for  validation/ 
verification.  This  type  of  assessment  is  made  before  production  is  initiated, 
during  production  in  the  form  of  in-process  reviews,  and  at  the  completion  of 
production  when  the  suitability  of  the  delivered  MOTD  is  verified  against  the 
svstem  design  and  support  criteria.  This  final  verification  assures  that  the 
technical  data  has  been  updated  to  agree  with  the  final  requirements  specifica- 
tion resulting  from  first  article  inspection  and  evaluation.  It  must  also  demon- 
strate that  the  MOTD  to  be  deployed  will  satisfactorily  provide  personnel  with 
the  information  necessary  to  conduct  operation  and  maintenance  in  support  of 
established  performance  goals.  The  goal  of  this  verification  and  demonstration 
is  to  test  the  technical  data  for  handling  durability,  accuracy  and  completeness 
of  information,  claritv  appropriate  for  use  at  the  intended  skill  levels,  ease  of 
access  and  updating. 

Accepted,  final  MOTD  is  replicated  and  distributed  to  fleet  user  activi- 
ties in  accordance  with  equipment  deployment  schedules,  training  activities 
in  accordance  with  training  schedules,  and  cognizant  support  and  administrative 
storage  activities.  NTIPP  requirements  resulting  from  this  activity  are  to 
assure  that  the  data  is  replicated  in  accordance  with  user/data  match  criteria 
and  that  distribution  requirements  are  met.  On  receipt  of  MOTD,  each  opera- 
tional and  training  activity  will  conduct  preliminary  reviews  to  identify  deficien- 
cies. NTIPP  will  coordinate  and  initiate  change  proposal  to  update  deployed 
data  and  assure  changes  are  distributed  to  using  activities.  In  addition,  NTIPP 
will  act  as  the  focal  point  for  collection  of  user  feedback  and  initiation  of  MOTD 
update  throughout  the  operational  life  of  the  system. 
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Figure  3-4.  Relationship  of  MOTD  to  System  Development  and  ILS  During  the  Production, 
Deployment,  and  Support  Phases  of  the  Weapon  System  Acquisition  Process. 
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3.8  REQUIRED  NTIPP  ACTIONS  DURING  WEAPON  SYSTEM  PRODUCTION/ 

DE  P LO Y M E NT/  SU  P POR T P RASES 

During  the  Production/Deployment/ Support  Phase,  the  final  MOTD  product  is 
developed  and  deployed  for  operational  use.  Consequently,  replication,  distribution, 
feedback,  and  update  become  the  most  critical  elements  of  the  MOTD  acquisition 
process. 

The  first  three  MOTD-related  events  during  the  Production/Deployment/ 
Support  phase  are  as  follows:  (1)  Establish  plans  and  schedules  for  production 
of  final  MOTD,  (2)  Conduct  in-process  reviews  to  insure  contractor  compliance 
with  established  plans  and  schedules,  and  (3)  Review  final  MOTD  and  verify 
compliance  with  requirements.  The  interaction  between  contractor  and  govern- 
ment personnel  initiated  during  Full-Scale  Development  is  continued  in  this 
phase.  The  military  agency  logistic  and  publication  review  teams  monitor 
contractor  operations,  provide  guidance  during  MOTD  development,  and  review 
the  final  product  in  much  the  same  manner  as  described  in  Topic  3.6  for  pre- 
liminarv  MOTD. 

The  fourth  MOTD-related  event  during  Production/Deployment/Support 
is  replication  and  distribution.  The  final  MOTD  is  replicated  in  required  quanti- 
ties and  distributed  to  the  following  activities:  (1)  Training  activities  in  accordance 
with  training  schedules,  (2)  Fleet  user  activities  in  accordance  with  equipment 
deployment  schedules,  and  (3)  Cognizant  support  and  administrative  activities 
for  storage. 

A primary  replication  concern  is  media  selection.  Since  several  poten- 
tial media  exist,  which  likely  will  be  narrowed  lown  to  one  or  two  as  NTIPP 
evolves,  the  functional  requirements  will  also  narrow.  However,  even  if  a 
new  medium  such  as  video  disc  is  determined  to  be  the  most  effective,  with 
the  protracted  time  (a  minimum  of  five  years)  to  make  the  transition,  conven- 
tionally printed  manuals  and  microforms  must  still  be  supported  in  the  early 
1980' s.  Therefore,  the  narrowing  process  and  transition  dictates  the  require- 
ment to  continue  to  provide  functional  capability  for  the  present  media  (printed 
books  and  microforms)  in  the  interim. 

The  requirements  of  distribution  are  primarily  to  deliver  MOTD  to  the 
using  activities  utilizing  the  most  efficient,  cost-effective  methods  and  maintain 
an  up-to-date  MOTD  configuration  index  of  all  users.  The  ultimate  goal  is  to 
provide  a distribution  system  and  a storage  system  that  will  be  centrally  con- 
trolled with  storage  facilities  strategically  situated  to  provide  rapid  delivery 
and  easy  availability  to  the  user.  The  distribution  system  will  evaluate  the  quan- 
tity and  type  of  MOTD  required  by  the  user,  deliver  the  MOTD  at  the  desired 
time,  and  establish  controls  on  distribution  from  a continuing  system  evaluation. 

The  fifth  MOTD-related  event  during  the  Production/Deployment/Support 
phase  is  the  establishment  of  feedback  channels  for  monitoring  MOTD  user  com- 
plaints and  the  initiation  of  the  MOTD  update  cycle.  Implementation  of  the  user 
feedback  and  update  cycles  must  include:  (1)  Evaluation  of  MOTD  effectiveness 
from  a User-Data  Match  and  training  viewpoint,  (2)  Evaluation  of  quality  control 
effectiveness,  and  (3)  Assessment  of  required  corrective  actions. 

The  objective  of  the  feedback  system  is  to  provide  the  means  for  the  user 
of  MOTD  to  report  discrepancies,  and  for  the  mechanisms  to  be  provided  so  that 
the  reported  information  can  be  acted  upon  (MOTD  update).  The  update  cycle  must 
include  a viable,  continuing  configuration  control  function  The  configuration 
control  function  would  provide  a list  of  the  equipment  for  which  each  user  is 
responsible,  the  current  change  status  of  each  equipment,  and  the  inventory  of 
the  TMs  the  user  is  maintaining. 


3-14 


< 


TABLE  3-IV.  REQUIREMENTS  INVOLVING  PRODUCTION/ 
DEPLOYMENT/SUPPORT  PHASES 


Reactive  Requirements 

Derived  Requirements 

• Establish  plans  and  schedules 
for  production  of  final  MOTD 

• Review  and  assess  contractor  plans  and 
schedules  for  the  following: 

— Risk  acceptability 
— Cost  bounds  and  acceptable  variables 
— Completeness  of  publications  tree  coverage 
— Compliance  with  established  User-Data 
Match,  training,  and  maintenance  philosophy 
criteria 

— Consideration  of  impact  of  other  related 
support  activities 

— Validation/Verification  considerations 

• Conduct  in-process  reviews  to 
insure  contractor  compliance 
with  established  plans  and 
schedules 

• Review  and  assess  final  MOTD  preparation 
with  respect  to  the  following: 

— Risk  management 
— Cost  management 

— Compare  MOTD  completed  to  date  with 
finalized  publication  tree 
— Variance  from  User-Data  Match,  training, 
and  maintenance  philosophy  criteria 
— Variance  from  planned  impact  of  other 
related  support  elements 
— Validation/verification  status 

• Review  final  MOTD  and  verify 
compliance  with  requirements 

• Assess  final  MOTD  with  respect  to  deviation 
from  plan  as  follows: 

— Risk  variance 
— Cost  variance 

— Variations  from  final  publications  tree 
— Variance  from  User-Data  Match,  training, 
and  maintenance  philosophy  criteria 
— Variance  from  planned  impact  of  other 
related  support  elements 

• Replicate  and  distribute  final 
MOTD  to  using  activities 

• Implement  plans  for  final  MOTD  replication 
and  distribution  as  follows: 

— Training  activities  in  accordance  with 
training  schedules 

- Fleet  user  activities  in  accordance  with 
equipment  deployment  schedule 
— Cognizant  support  and  administrative 
activities  storage 

• Establish  feedback  channels  for 
monitoring  MOTD  user  complaints  a 
and  initiate  update  cycle 

• Implement  user  feedback  and  MOTD  update  cycle 
— Evaluate  effectiveness  from  User-Data 
Match  and  training  viewpoints 
- Evaluate  quality  control  effectiveness 
— Assess  required  corrective  actions 
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4.  1 USER-DATA  MATCH  REQUIREMENTS 

Requirements  for  the  User-Data  Match  will  impact,  directly  or  indirectly,  many 
NTIPP  issues.  Acquisition,  content  generation,  and  the  head/data/training  trade- 
off will  be  among  the  areas  of  highest  impact,  resulting  from  the  successful  applica- 
tion of  the  User-Data  Match  model  to  the  design  and  development  of  MOTD. 

The  goal  of  the  User-Data  Match  is  to  assure  that  technical  documentation 
meets  all  the  user's  data  needs  and  requirements.  By  meeting  these  needs  and 
requirements,  major  MOTD  defects  will  be  eliminated,  thus  improving  MOTD 
usability  and  credibility.  It  is  anticipated  that  improved  MOTD  usability  and 
credibility  will  increase  Fleet  operati  >nal  readiness  and  decrease  equipment/ 
system  support  life  cycle  costs.  At  this  time  it  is  impossible  to  quantify  exact 
cost  savings  or  precisely  measure  the  amount  of  increased  Fleet  operational 
readiness,  because  data  in  these  areas  either  does  not  exist  and  cannot  be  deter- 
mined without  inferential  analysis,  or  is  not  readih  available,:  Therefore,  until 
such  time  as  such  data  do  exists  in  usable  form,  only  qualifiable  assumptions 
based  on  the  evidence  at  hand  can  be  made. 

The  user-data  match  research  issue  will  result  in  a methodology  or  model 
and  set  of  guidelines  for  the  development  of  MOTD  in  its  most  useful  form  based 
on  an  effective  balance  among  the  various  combinations  of  user  personnel  charac- 
teristics; job  tasks  as  dictated  by  the  equipment/systems  worked  on;  environmen- 
tal conditions;  training  considerations;  maintenance  philosophy;  and  appropriate 
formats  and  media  techniques  for  the  presentation  of  MOTD.  This  "model” 
will  not  only  be  developed,  but  specific  methods  of  applying  it  will  be  included. 

The  model  and  accompanying  guidelines  will  provide  the  framework  for  making 
the  necessary  decisions  involved  with  the  design  and  development  of  an  MOTD 
package,  and  will  provide  the  theoretically  best  balance  among  all  the  variables. 
Additionally,  since  most  MOTD  is  developed  with  numerous  constraints  already 
imposed  upon  the  developer,  the  methodology  will  also  enable  reasonable,  justi- 
fiable decisions  to  be  made  in  light  of  the  imposed  constraints. 

User-Data  Match  requirements  generally  address  problem  areas  identified 
during  the  analysis  of  current  and  proposed  TM  systems.  These  problem  areas 
include  the  overwhelming  lack  of  human  factors  considerations  found  in  most  cur- 
rent and  proposed  acquisition  specifications,  policies,  and  procedures;  the  cur- 
sory awareness  paid  to  the  user's  data  needs  by  the  content  generator;  non- 
implementation of  existing  human  engineering  principles  presently  found  in  Lo- 
gistic Support  Analyses;  and  the  paramount  need  for  a Head/Data/Training  Trade- 
Off  which  will  determine  how  the  user  is  to  acquire  the  necessary  data  and  skill 
he  needs  to  successfully  operate/maintain  the  equipment  he  must  support. 

In  addressing  the  problem  of  the  lack  of  human  factors  considerations 
found  in  current  and  proposed  acquisition  policies  and  procedures,  it  becomes 
evident  that  the  User-Data  Match  must  specify  what  human  factors  considerations 
should  be  incorporated  into  the  acquisition  specifications,  etc.  These  User-Data 
Match  acquisition  requirements  will  specify  the  manner  in  which  the  content 
generator  must  develop  his  MOTD  product  from  a human  engineering  standpoint, 
and  specify  the  information  the  content  generator  must  know  in  order  to  produce 
optimal  MOTD,  matched  as  effectively  as  possible  to  the  user.  In  order  to 
achieve  this  match,  the  following  User-Data  Match  component  information  require- 
ments must  be  fulfilled: 

Personnel  Characteristics  — The  user  personnel  characteristics  which 
must  be  identified  and  taken  into  consideration  are  Basic  Test  Battery  scores 
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4.1  USER-DATA  MATCH  REQUIREMENTS  (Continued) 


which  indicate  arithmetic  reasoning  (ARI),  mechanical  comprehension  (MECH>, 
and  basic  intellectual  ability  (GCT);  Navy  rate,  rating,  or  specialty  within  rating; 
reading/comprehension  ability;  years  of  related  on-the-job  experience;  formal 
education;  Navy  schooling;  etc.  (With  regard  to  Navy  schooling,  it  is  important 
to  note  that  elemental  maintenance  philosophy  differences  exist.  NAVA1R  school- 
ing is  generally  based  on  "black-box”  replacement,  whereas  NAVSEA  and 
NAVE  LEX  schooling  is  based  on  "repair -in-place"  philosophy. ) 

Equipment/Systems  and  Task  Analysis  - Another  information  requirement 
is  a detailed  analysis  of  the  equipment/systems  the  technician  works  on.  This 
analysis  should  include  a comprehensive  description  of  the  equipment/system;  a 
complete  functional  job  task  analysis  of  the  duties  the  technician  must  perform 
with  respect  to  the  equipment/systems;  and  a definition  of  the  maintenance  philos- 
ophy imposed  on  that  system.  This  definition  should  encompass  such  things  as 
level  of  fault  isolation;  mean  time  to  repair  the  equipment/systems  failures; 
existence  of  Built-In  Test  Equipment,  Automated  Test  Equipment,  or  computer 
diagnostics;  and  the  need  for  manual  troubleshooting. 

Environmental  Constraints  - Environmental  variables  which  may  impact 
the  technician's  ability  to  use  and  comprehend  the  MOTD  must  be  designated. 
These  environmental  information  requirements  include  such  items  as  illumination, 
wind,  noise  dust,  dampness,  workspace  restrictions,  etc. 

Presentation  Techniques  - Of  major  importance  in  achieving  an  effective 
user-data  match  are  the  information  requirements  which  relate  to  presentation 
techniques.  These  techniques,  which  are  employed  to  present  the  MOTD  to  the 
user,  fall  into  two  categories  - formats  and  components  of  formats  (such  as 
JPA,  FOMM,  hybrid,  etc.),  and  media  (paper  manual,  microform,  videodisc, 
etc. ) Information  concerning  these  techniques  must  relate  to  their  appropriate- 
ness and  the  effectiveness  with  which  they  present  specified  types  of  data  to 
specified  users  according  to  the  methodology  of  the  user-data  match.  Essen- 
tially, what  is  required  for  each  technique  is  an  evaluation  of  its  effectiveness 
of  communication  within  certain  parameters  (as  specified  by  the  procuring 
agency). 

Very  little  attention  appears  to  be  paid  by  the  content  generator  to  human 
factors  considerations  during  the  design  and  development  of  MOTD.  Following 
the  data  acquisition  rules,  policies,  and  procedures,  the  content  generator  per 
forms  the  human  transformation  of  engineering/manufacturing/maintenance  data 
into  MOTD.  As  a consequence  of  human  involvement,  the  transformation  output 
is  often  subject  to  interpretations,  biases,  inadequacies,  and  errors.  Therefore, 
it  is  imperative  that  the  data  acquisition  rules,  policies  and  procedures  provide 
explicit  guidelines  for  use  of  the  user-data  match  model  or  methodology  by  the 
content  generator.  Also,  it  is  important  that  the  content  generator  get  instruc- 
tions or  guidelines  for  conducting  the  Head/Data/Training  Trade-Off  and  Readi- 
bility/Comprehensibility  guides  for  text  and,  if  possible,  graphics. 

Under  the  current  system  of  MOTD  development,  some  level  of  Logistics 
Support  Analysis  is  usually  conducted.  (This  type  of  analysis  will  probably 
continue  to  be  a part  of  future  MOTD  development  systems  also. ) The  LSA 
typically  provides  guidelines  for  the  matching  of  MOTD  to  its  users.  However, 
these  guidelines  are  usually  vague  and  often  are  not  implemented. 
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Theoretically,  the  LSA  could  provide  much  of  the  data  necessary  to  fulfill 
the  User-Data  Match  Component  Information  Requirements.  I'he  LSA  spec  MIL- 
STD-1388  (used  by  all  services)  indicates  that  requirements  such  as  maintenance 
support  concept  equipment  /systems  components  including  support  and  test  equip- 
ment, technical  data,  facilities,  personnel  and  training  requirements,  environ- 
mental constraints,  etc. , be  specified  for  each  equipment  system.  However,  this 
specification  is  not  nearly  detailed  or  comprehensive  enough  for  User-Data  Match 
purposes;  additionally,  the  methods  of  application  are  never  formally  addressed. 
LSA  specification  requirements  must  be  specific  enough  so  that  fulfilling  the 
User-Data  Match  component  information  requirements  can  be  readily  performed 
by  the  Content  Generator  at  a reasonable  cost. 

Various  requirements  with  regard  to  training  must  be  met  if  the  MOTD  is 
to  effectively  match  the  user's  needs.  The  Ilead/Daia/Training  Trade-Off  is  the 
process  by  which  these  requirements  can  be  fulfilled.  During  this  trade-off,  the 
critical  decisions  are  made  concerning  how  the  user  is  to  acquire  the  necessary 
data  and  skills  to  satisfactorily  operate/maintain  the  equipment/systems  he  must 
support.  As  part  of  the  trade-off,  information  must  be  gathered  and  assessed 
regarding  each  component  of  the  trade-off:  The  "Head,"  the  "Data,”  and  the 
"Training."  Information  requirements  with  respect  to  the  "Head"  are  items  such 
as  the  amount  of  formal  education  the  user  has  already  obtained,  the  user's  prior 
job  experience,  Navy  schooling  or  training  completed,  general  capabilities,  as 
indicated  by  the  ARI,  MECH,  and  GTC  scores,  etc. 

With  regard  to  the  "Data,"  the  total  data  content  needed  to  support  the 
equipment /systems  must  be  assessed.  This  includes  task  data  used  during  job 
performance  and  system  descriptions  used  prior  to  job  performance.  Also,  the 
manner  in  which  all  or  parts  of  this  data  can  best  be  transformed  into  useful 
MOTD  must  be  specified  in  terms  of  format  and  media  techniques.  It  is  recog- 
nized that  very  limited  human  factors  research  exists  in  the  Head/Data  interface 
area.  For  this  reason,  it  is  the  obligation  of  NTIPP  to  accomplish  this  research 
for  this  specific  application.  For  example,  which  components  of  presentation 
techniques  are  best  suited  for  portraying  MOTD  for  the  performance  of  specific 
kinds  of  job  tasks?  Obviously,  most  of  these  "Head/Data"  information  require- 
ments are  highly  similar,  if  not  identical,  to  the  User-Data  Match  component 
information  requirements.  Therefore,  to  fulfill  both  sets  of  requirements  it 
would  only  be  necessary  to  gather  and  assess  this  information  once. 

However,  in  addition  to  the  "Head"  and  "Data"  Information  Requirements 
there  are  "Training"  requirements  which  must  be  addressed.  These  include 
making  a determination  of  what  portion  of  the  data  content  could  the  user  best  ac- 
quire by  formal  training,  and  what  portion  by  MOTD,  taking  costs  various  types 
of  training  and  various  MOTD  presentation  techniques  into  consideration.  In 
other  words,  of  the  total  information  the  technician  will  require,  what  portion 
must  be  recalled  from  memory  during  task  performance  and  what  portion  should 
the  technician  obtain  from  MOTD  during  taks  performance?  The  information 
should  be  determined  by  representatives  of  the  training  community  and  MOTD 
development.  Other  requirements  include  the  need  for  a determination  of  whether 
the  equipment/system  will  include  BITE,  ATE,  or  computer  diagnostics;  a de- 
termination  of  what  types  of  training  would  be  most  advantageous  to  the  user 
taking  into  consideration  his  capabilities  and  characteristics;  a determination  of 
the  level  of  performance  effectiveness  expected  of  the  user;  a determination  of 
how  basic  learning  principles  could  be  systematically  applied  in  the  design  and 
development  of  training  materials  and  MOTD;  etc. 

Table  4-1  lists  the  requirements  inherent  in  the  User-Data  Match.  Ihese 
requirements  resulted  from  the  analysis  of  current  and  proposed  TM  systems 
and  through  various  discussions  with  informed  sources  with  whom  N 1 IPP  repre- 
sentatives interfaced.  This  list  is  not  intended  to  be  all-inclusive;  further  re- 
search may  very  well  uncover  additional  User-Data  Match  requirements 
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TABLE  4-1.  USER-DATA  MATCH  REQUIREMENTS 

User-Data  Match  Component  Information  Requirements: 

Objective:  to  specify  the  human  factors  considerations  which  should  be  incorporated 

into  data  acquisition  specifications,  policies,  and  procedures. 

Personnel  Characteristics: 

• identify  User's  Navy  rate,  rating,  and  specialty  within  rating 

• determine  User's  Basic  Test  Battery  Scores  (ARI,  MECH,  GCT) 

• assess  User's  related  on-the-job  experience  (years  of) 

• determine  User’s  formal  education 

• determine  User's  Navy  schooling/training  completed 

• etc. 

Equipment/Systems  and  Task  Analysis: 

• comprehensive  description  of  equipment/systems 

• complete  job  task  analysis  of  duties  User  must  perform  with  respect  to 
equipment/systems 

• define  and  specify  aspects  of  maintenance  philosophy 

level  of  fault  isolation 

meantime  to  repair  equipment/system  failure 
existence  of  Bite,  Ate  or  computer  diagnostics 
need  for  manual  trouble  shooting 

Environmental  Constraints: 

• identify  environmental  variables  which  may  impact  User's  ability  to  use  and 
comprehend  MOTD 

illumination 

wind 

noise 

dust 

dampness 

workspace  constraints 
etc. 

Presentation  Techniques: 

• evaluate  various  forms  of  formats  and  components  of  formats  to  determine 
the  appropriateness  or  effectiveness  with  which  each  presents  specified 
types  of  data  to  the  User.  (Formats  include  JPA,  FOMM,  ITDT,  etc/com- 
ponents of  formats  include  use  of  procedural] zed  instructions,  use  of  color 
diagrams/illustrations,  use  of  theory,  etc.) 

• evaluate  various  forms  of  media  to  determine  the  appropriateness  or  effec- 
tiveness with  which  each  presents  specified  types  of  data  and  formats  to  the 
User  (media  include  paper  manual,  audiovisual,  microform,  video  disc, 
etc. ) 

Content  Generator  User-Data  Match  Requirements: 

Objective:  to  guide  MOTD  design  and  development  so  that  all  user  needs  are  met 

effectively. 

(these  requirements  are  covered  in  greater  detail  in  the  Content  Generation  Require- 
ments topic  which  follows. ) 
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TABLE  4-1.  USER-DATA  MATCH  REQUIREMENTS  (Continued) 

Data  Acquisition  User-Data  Match  Requirements: 

Objective:  to  specify  data  acquisition  rules,  specifications,  policies  and  procedures 

which  provide  explicit  guidelines  for  use  of  User-Data  Match  model  or  meth- 
odology by  the  Content  Generator,  and  suggest  methods  for  collection  of 
necessary  information  relative  to  use  of  model. 

specify  guidelines  for  conduct  of  Head/Data/Training  Trade-Off  (see  addi- 
tional discussion  below) 


specify  guidelines  on  readability /comprehensibility  of  text  and  graphics  (if 
possible) 

Logistics  Support  Analysis  User-Data  Match  Requirements: 

Objective:  to"enable  the  critical  decisions  affecting  MOTD  development  and  training  to 
be  made  based  on  most  complete  and  accurate  information. 


- Personnel  Characteristics 

- Equipment/Systems  and  Task  Analysis 

- Environmental  Constraints 

- Presentation  Techniques 

- Training  Considerations 


These  requirements  are  basically 
the  same  as  those  listed  under 
User-Data  Match  Component  Infor- 
mation Requirements 

These  are  discussed  in  detail  below 
under  Head/Data/Training  Trade- 
Off  Requirements. 


Head/Data/Training  Trade-Off  Requirements: 

Objective:  to  enable  the  critical  decisions  to  be  made  regarding  how  the  User  is  to 
acquire  the  necessary  knowledge  and  skills  to  satisfactorily  operate/ 
maintain  the  equipment/sy stems. 

"Head  Information  Requirements”: 

• Amount  and  quality  of  User's  formal  education 

• User's  related  job  experience 

• Navy  schooling/training  User  has  completed 

• User’s  general  capabilities  (ARI,  MECH,  GCT) 

• User's  reading/comprehensibility  level 

• etc. 


Data  Information  Requirements: 

• determine  total  data  content  needed  to  support  equipment/systems 

• determine  manners  in  which  this  data  can  best  be  transformed  into  useful 
MOTD  (specified  in  terms  of  Format  and  Media  techniques) 

• etc. 

Training  Information  Requirements: 

• determine  what  portion(s)  of  total  data  content  the  user  should  acquire 
through  training  (information  required  to  be  recalled  by  memory),  and 
what  portion  by  MOTD,  taking  costs  of  various  training  types  and  various 
MOTD  presentation  techniques  into  consideration 

• determine  whether  BITE,  ATE,  computer  diagnostics  will  be  present 

• determine  which  types  of  training  would  be  most  appropriate  considering 
User  capabilities,  data  content,  cost,  etc. 

• determine  level  of  performance  effectiveness  expected  of  User 

• determine  whether  MOTD  can  be  developed  for  use  in  training  also 

• determine  how  basic  learning  principles  could  be  incorporated  into  the 
design  and  development  of  training  materials  and  MOTD 

• etc. 
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The  NTIPP  requirements  for  data  acquisition  must  provide  for  processes,  and  for 
guidelines,  content,  structure,  and  application  for  Navy  policies  and  procedures 
concerned  with  TM  acquisition  and  maintenance.  

The  NTIPP  requirements  for  data  acquisition  were  developed,  in  part, 
as  a result  of  the  research  done  in  Task  1 of  this  study.  Policy  and  procedure 
documents  for  all  DoD  components  were  searched  for  those  items  which  each 
component  addressed  as  requirements  necessary  for  TM  acquisition.  All  DoD 
components  were  visited,  with  emphasis  on  Navy  SYSCOM's,  to  discuss  actual 
practices.  Another  source  of  information  was  knowledge  which  Hughes  Aircraft 
Company  has  gained  over  many  years  of  preparing  TMs  for  all  DoD  components. 

In  addition,  TM  specifications  used  by  all  DoD  components  were  given 
a rigorous  examination  and  analysis.  First-hand  knowledge  of  Hughes  personnel 
experienced  in  the  use  of  these  specifications  to  generate  various  types  of  TMs 
was  invaluable  in  this  endeavor.  Requirements  for  a wide  range  of  TMs,  content 
material  for  different  maintenance  activities,  required  coverage  for  various 
types  of  military  equipment,  and  a multitude  of  TM  processes  were  extracted 
as  a result  of  this  effort.  Past  and  current  studies  of  TM  specifications  per- 
formed by  Hughes,  RCA,  Kinton,  Hydrospace  Challenger,  and  other  companies 
for  various  DoD  components  were  also  consulted  for  new  ideas  in  specification 
requirements.  Other  documents  of  interest  to  Task  2 which  were  collected  during 
the  Task  1 survey  included  experimental  evaluations  of  concepts  and  techniques 
that  have  been  developed  and  compared  with  other  techniques.  These  and  human 
factor  studies,  past  and  present,  are  significant  in  determining  NTIPP  require- 
ments for  data  acquisition. 

The  results  of  a present  NTIPP  human  factors  subcontract  with  Anacapa 
Sciences,  Inc.  , Santa  Barbara,  California,  are  expected  to  have  major  impact 
on  the  requirements  for  TM  specifications.  For  this  reason,  TM  specification 
requirements  were  defined  to  be  broad  enough  in  scope  to  accommodate  these 
expected  refinements.  Refinements  will  likely  include  amplification  of  TM  speci- 
fication requirements  in  the  areas  of  (1)  what  kind  of  materials  a TM  should 
contain,  (2)  how  much,  (3)  to  what  level,  and  (4)  how  it  can  be  most  effectively 
presented.  Table  4-II  lists  the  data  acquisition  requirements. 

These  and  other  refinements  to  NTIPP  data  acquisition  requirements  will 
continue  through  other  phases  of  this  study.  During  the  next  phase  of  the  pro- 
gram, baseline  and  alternate  sets  will  be  selected  which  satisfy  these 
requirements. 

In  developing  data  acquisition  requirements  for  NTIPP,  it  was  necessary 
to  consider  the  interrelationships  among  all  elements  from  which  the  require- 
ments evolved.  While  it  would  be  exciting  to  believe  that  each  requirement  selec- 
tion could  be  based  on  some  exotic  multifactor  equation  that  properly  weighs 
and  balances  various  criteria  to  select  the  best  requirement  for  each  circum- 
stance, it  also  would  be  a delusion  to  think  this  could  be  suitable  for  all  individ- 
ual elements  considered.  Due  to  the  nature  of  many  of  the  elements  which  com- 
prise the  requirements,  many  engineering  judgment  calls  were  necessary. 

Even  with  relatively  unlimited  time  and  money,  it  is  unlikely  that  a mathemati- 
cally contrived  method  for  selecting  one  requirement  element  over  another  could 
j be  devised.  With  limited  time  and  money,  an  understanding  of  the  primary 

criteria  for  each  requirement,  i.  e. , what  must  it  accomplish,  along  with  some 
g simple  and  straightforward  methods  of  making  necessary  evaluative  judgments, 
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is  all  that  was  needed  in  the  majority  of  cases  to  select  the  NTIPP  requirement 
for  data  acquisition  which  are  suited  to  a variety  of  applications. 

Policy  and  Procedure  Requirement  Considerations  - A definition  of  NTIPP 
data  acquisition  policy  and  procedure  requirements  is  necessary  for  future  devel- 
opment of  an  all-encompassing  NTIPP  system.  In  the  generation  of  these  require- 
ments, a discrete  set  of  criteria  were  employed  to  ensure  complete  coverage  of 
all  aspects  of  technical  manual  acquisitions.  This  development  of  NTIPP  require- 
ments is  a natural  outgrowth  of  the  efforts  conducted  in  Task  1 of  this  study,  and 
will  subsequently  provide  the  basis  for  the  evolution  of  a baseline  and  alterna- 
tives. These  requirements,  once  developed,  were  then  subjected  to  further  re- 
finement and  ratification. 

One  criterion  in  developing  the  NTIPP  data  acquisition  requirements  was 
to  assess  all  relevant  requirements  of  the  Department  of  Defense,  Secretary  of 
the  Navy,  and  Chief  of  Naval  Operations  that  would  or  could  be  met  within  the 
developed  framework.  An  equally  essential  criterion  was  to  assure  that  the 
requirements  could  encompass  any  future  pertinent  advances  in  the  state-of-the- 
art.  An  additional  criterion  was  to  assure  that  the  developed  requirements 
enveloped  all  the  existing  requirements  contained  in  the  various  SYSCOMs  with- 
out necessarily  adhering  to  their  extant  degree  or  methods  in  function 
performance. 

In  the  actual  development  of  NTIPP  data  acquisition  requirements,  each 
of  the  individual  SYSCOM  requirements  (which  had  been  previously  derived  from 
the  Task  1 analysis  of  various  SYSCOMs  and  subsequently  itemized)  were  func- 
tionally grouped  without  regard  to  the  originator.  Subsequent  analysis  of  these 
functional  groups,  with  some  shuffling  of  requirements  from  one  group  to  another, 
produced  a listing  of  functional  sets  of  detailed  requirements.  A single-sentence 
description  at  a higher  level  than  but  encompassing  each  of  the  contained  detailed 
requirements  for  each  set  was  then  developed.  A similar  exercise  was  conducted 
for  DoD,  SECNAV,  OPNAV,  and  NAVMAT  requirements,  and  the  resultant  sen- 
tence listing  compared  to  and  interleaved  with  the  SYSCOM  listing.  This  single 
remaining  listing  was  reviewed,  refined  and  then  evaluated  for  essentiality  and 
intent  of  purpose. 

These  developed  upper-level  NTIPP  data  acquisition  requirements  will 
subsequently  be  utilized  in  preparing  a baseline  system  description.  They  will 
provide  the  necessary  framework  to  build  the  baseline,  and  will  bound  the  devel- 
opment of  potential  alternative  systems.  Since  they  are  high-level  requirements, 
they  allow  adequate  room  for  innovation  in  the  system  design,  and  are  not  restric- 
tive as  to  techniques  that  could  be  employed  in  development.  The  baseline  design 
and  the  alternatives  will,  of  course,  be  subjected  to  trade-off  studies  and  cost/ 
effectiveness  analyses  prior  to  the  finalization  of  the  NTIPP  design. 

The  NTIPP  data  acquisition  policy  and  procedures  requirements  shown 
in  Table  4-II  primarily  stress  centralized  management  in  TM  acquisitions  and 
maintenance.  Inherent  within  the  centralized  management  concept  is  the  connota- 
tion of  standardization.  With  the  continued  decrease  during  the  past  two  decades 
in  the  size  of  our  Navy  and  the  continued  increase  in  cross-utilization  of  avia- 
tion, surface  and  submarine  personnel,  a single  standard  for  data  acquisition  is 
becoming  increasingly  necessary. 

TM  Specification  Requirement  Considerations  — The  requirements  for 
technical  manual  specifications  must  contain  the  three  basic  elements  of  data 
transfer  - content,  format,  and  media.  Content  is  the  data  that  is  to  be  trans- 
ferred to  the  technical  manual  user;  format  is  the  means  of  organizing  and 
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4.2  DATA  ACQUISITION  REQUIREMENT  (Continued) 


portraying  such  data  for  transfer;  and  media  is  the  means  for  capturing  the  for- 
matted data  for  retention  and  subsequent  transfer  to  the  user. 

Content  is  the  primary  requirement,  and  depends  on  user  needs.  Con- 
tent requirements  are  governed  by  equipment  type,  equipment  complexity,  user 
training  and  experience,  and  task  requirements.  The  content  requirements  are 
independent  of  the  format  and  media  requirements.  Format  depends  both  on  the 
content  and  media  requirement,  and  is  governed  by  the  type  of  data  that  is  to 
be  transferred,  the  environment  in  which  the  data  is  used,  the  manner  in  which 
the  data  is  used,  the  media  by  which  the  data  is  to  be  transferred,  the  training, 
experience,  and  skill  of  the  user.  Media  requirements  are  governed  primarily 
by  the  environment  in  which  the  data  is  to  be  used  and  by  the  content 
requirements. 

In  addition  to  the  data  transfer  requirements,  technical  manual  specifica- 
tion requirements  must  contain  information  on  the  scope,  purpose,  and  appli- 
cability of  the  specification,  quality  assurance  provisions,  and  preparation  re- 
quirements. The  scope,  purpose,  and  applicability  of  the  specification  must 
define  the  type  and  purpose  of  the  technical  manual  to  be  produced,  and  the 
equipment  types  to  which  the  specification  applies.  Quality  assurance  provisions 
must  contain  inspection  requirements  and  measures  necessary  during  and  after 
preparation  of  the  technical  manual  to  assure  that  the  manual  is  complete, 
accurate,  comprehensible,  and  usable. 

Preliminary  user-data  match  findings  indicate  that  the  use  of  short, 
simple  words  and  a consistent  style  and  format  are  necessary  specification 
requirements.  Liberal  use  should  be  made  of  examples  and  illustrations  to 
demonstrate  the  requirements.  The  objectives,  principles,  and  purpose  of  the 
requirements  should  be  given  in  order  to  clarify  the  requirements.  Reference 
to  other  specifications  and  documents  for  requirements  should  not  be  made  unless 
all  of  the  referenced  requirements  apply.  If  exceptions  to  referenced  require- 
ments are  taken,  they  should  be  clearly  spelled  out.  Specification  requirements 
must  tie  the  TM  content  requirements  to  a maintenance  plan  to  assure  that  all 
data  needed  by  the  user  is  contained  in  the  manual,  and  that  all  data  contained 
in  the  manual  is  applicable  to  the  user  needs.  In  addition  to  containing  the  re- 
quirements for  the  data  to  put  in  the  manual,  specification  requirements  must 
contain  guidelines  on  how  to  prepare  the  data. 


TABLE  4 -II.  DATA  ACQUISITION  REQUIREMENTS 


I’M  Specifications  for  Content 


• Provide  method  to  assure  formulation  and  analysis  of  detailed  equipment 
maintenance  requirements  to  guarantee  the  completeness  of  a TM  in 
supporting  a commodity  with  data  which  is  also  usable  by  the  skill  level  (s) 
for  which  the  TM  is  designed. 

• Provide  guidance  in  the  preparation  of  text  and  procedures  for  various 
equipment  complexities  vs  amount  of  built-in-test  features  and  relation- 
ships to  maintenance  philosophy  and  user  skill  levels. 

• Provide  description  of  various  methods  and  techniques  to  encourage  TM 
use,  enhance  user  skills,  and  increase  his  understanding  of  his  equipment 
and  job. 

• Provide  flexibility  in  describing  depth  and  scope  of  text  which  is  best 
suited  for  commodities  requiring  data,  and  intended  users  of  data,  for 
both  descriptive  and  maintenance  information. 

• Provide  guidance  on  proper  vocabulary  usage  and  text  structure  for 
intended  audience. 

• Define  meaningful  schedules  for  in-process  reviews  and  sample  lots  to 
be  inspected. 

• Provide  definitive  requirements  for  validation  and  verification  of  TM, 
criteria,  scheduling,  equipment  required,  and  record  keeping. 

• Include  comprehensive  quality  assurance  procedures  for  content  generator, 
in  accordance  with  readability,  comprehensibility,  accuracy,  and  usability 
guidelines  developed  for  user-data  match. 

TM  Specifications  for  Format/Media 


• Provide  flexibility  in  describing  types  of  illustrations  which  are  best 
suited  for  commodities  requiring  data,  and  intended  users  of  data,  for 
both  descriptive  and  maintenance  information. 

• Provide  for  effective  use  of  illustrations  in  physical  and  functional  de- 
scriptions with  libera]  use  of  keyed  text /illustration  relationships,  as 
defined  by  user-data  match. 

• Emphasize  both  text  and  illustration  examples  and  samples.  Both  ''good" 
and  "bad"  examples  should  be  included  and  all  examples  should  demon- 
strate correctly  the  principles  and  techniques  being  illustrated  or 
proposed. 

• Provide  flexibility  and  guidance  in  the  use  of  existing  meida  presentation 
methods  such  as  hard  copy,  microforms,  audio-visual,  or  digital  devices. 
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4.2  DATA  ACQUISITION  REQUIREMENTS  (Continued) 


TABLE  4-II,  DATA  ACQUISITION  REQUIREMENTS  (Continued) 


• Provide  definitive  guidance  in  the  requirements  for  TM  structure  and 
the  inclusion  of  various  TM  elements,  defined  by  user  needs,  format 
used,  equipment  complexity  and  intended  environment  of  use. 

• Provide  coordination  and  requirements  for  timely  generation  and  struc- 
ture of  material  for  multi-usage  of  TM  in  training  classes,  in-process 
reviews,  and  quality  control  sampling. 

• Demonstrate  user-data  match  requirements  for  formats  to  be  used  and 
their  preparation. 

• Provide  for  logical  arrangement  of  TM  content  for  ease  of  use. 

• Provide  for  fast  and  easy  access,  comprehensive  indexing,  and  simpli- 
fied, as  well  as  descriptive,  numbering/divisions/titles/headings. 

• Provide  for  flexibility  and  variety  of  type  and  fonts,  explicit  covers, 
paper  and  film  grades,  TM  sizes,  and  packaging  techniques  for  user 
need  and  environmental  conditions. 

TM  Acquisition  Policies  and  Procedures 


• Provide  command  structure  with  necessary  authority  for  the  manage- 
ment, control,  coordination,  issue,  and  implementation  of  policies  and 
procedures  for  the  acquisition,  and  maintenance,  of  technical  manuals 
to  include: 


- Planning 

- Contractor /military  interfaces 

- Requirements  determination 

- In-process  reviews 

- Validation/Verification 

- Change /update  procedures 


- Reproduction 

- Distribution/stocking 

- Generation 

- Acceptance 

- Development 

- Reri  sion 


• Provide  point  of  contact  for  Fleet  and  other  Navy  activities  on  TM 
matters. 


• Provide  control  and  cognizance  over  Navy  TM  research  and  develop- 
ment activities  and  maintain  liaison  with  other  DoD  Service  branches. 


• Provide  point  of  contact  and  implement  procedures  for  accumulating 
itemized,  accurate,  cost  data,  liaison  with  CNM  Comptroller  on  fund- 
ing and  budget  matters,  and  dispersion  and  utilization  of  funds  for  TM 
acquisition,  maintenance,  and  R&D. 


• Provide  control  of  policy  documents,  TM  specifications,  standards, 
contract  documents,  style  guides,  and  handbooks;  their  issuance, 
update,  applicability  to  individual  procurements  and  processes  and 
maintain  liaison  with  other  DoD  service  branches  on  related  matters. 
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TABLE  4 -II.  DATA  ACQUISITION  REQUIREMENTS  (Continued) 


• Establish  and  maintain  hardware-configuration  and  TM-configuration 
indexing  or  listings  which  are  tied  to  various  equipment  change  pro- 
cedures and  routine  TM  maintenance. 

• Provide  coordination  and  utilization  of  in-house  capabilities  for  all  Navy 
TM  services. 

• Provide  control  and  point  of  contact  for  logistic  guidance  with  hardware 
acquisition  activities  on  all  TM  related  matters. 


I 
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4.3  CONTENT  GENERATION  REQUIREMENTS 


Requirements  for  the  Content  Generation  Research  Issue  are  defined  in  order  to 
constrain  the  baseline  and  alternative  configurations  of  this  functional  entity  within 
acceptable  bounds  of  performance,  feasibility,  and  affordability. 

The  content  generating  activity  is  normally  a military  contractor;  how- 
ever, it  may  also  be  a military  agency  in-house  capability.  This  function  is 
responsible  for  collecting  the  data,  preparing  technical  publications  planning 
documents,  writing  the  TM,  critiquing  the  TM  and  performing  validation.  Since 
a vast  majority  of  Navy  MOTD  will  continue  to  be  developed  by  the  military  con- 
tractor, the  content  generation  requirements  focus  on  the  organization,  opera- 
tional procedures,  and  performance  capabilities  of  these  activities.  The  intent 
of  these  requirements  is  the  development  of  content  generation  baseline  and 
;ilternative  configurations,  all  of  which  have  the  capacity  to  produce  acceptable 
Navy  MOTD  products  in  a cost/effective  manner. 

Content  generation  requirements  must  be  flexib1  enough  to  accommodate 
contractor  differences  based  on  size,  available  resources,  management  philos- 
ophy, organization  structure,  hardware  product  line,  and  necessity  to  respond  to 
customers  other  than  the  Navy.  In  this  manner,  no  contractor  that  is  capable  of 
developing  quality  Navy  MOTD  products  will  be  eliminated  from  consideration. 
Additionally,  the  Navy  will  not  deplete  its  industry  resource  and  decrease  its 
options  based  on  a possible  reduction  in  the  current  number  of  contractor 
competitors. 

At  the  same  time,  content  generation  requirements  must  be  stringent 
enough  to  ensure  Navy  confidence  that  all  contractors  which  are  considered  quali- 
fied to  bid  on  MOTD  contracts  will  be  capable  of  delivering  products  which  meet 
Navy  standards  of  quality  in  a cost/effective  manner. 

The  analysis  of  current  and  proposed  technical  manual  systems  revealed 
many  variations  in  the  characteristics  of  content  generating  activities.  The  per- 
sonnel qualifications  of  MOTD  generators,  the  extent  to  which  MOTD  develop- 
ment is  subcontracted,  and  the  level  to  which  engineering/manufacturing  data 
base  development  is  automated  are  but  a few  of  the  areas  where  differences  exist. 
As  a result,  the  content  generation  requirements  must  lead  to  baseline  and  alter- 
native configurations  which  are  compatible  with,  and  able  to  evolve  from,  current 
and  proposed  contractor  configurations.  The  analysis  of  current  and  proposed 
TM  systems  also  uncovered  numerous  content  generation  problem  areas  such  as 
the  lack  of  structured  interaction  among  contractor  activities  involved  in  TM  de- 
velopment, training,  maintenance  engineering  and  provisioning,  and  the  failure 
of  MOTD  generators  to  have  sufficient  "hands-on"  equipment  experience  as  well 
as  familiarity  with  the  field  maintenance  environment.  The  content  generation 
requirements  are  structured  so  that  the  resulting  configurations  will  address  all 
of  these  problems. 

The  requirements  detailed  in  Table  4-III  are  arranged  to  coincide  with 
the  structure  upon  which  the  analysis  of  current  and  proposed  content  generation 
systems  was  based.  Overall  content  generation  issue  requirements  are  present- 
ed fir  ..  followed  by  requirements  for  each  of  the  six  sub-issues  — Engineering/ 
Manufacturing  Data  Rases,  Pre-Writing  Tasks,  Writing  Tasks,  Post- Writing 
Tasks,  TM  Presentation  Techniques  Handbooks,  and  Writer's  Guides  or 
Rcadability/Comprehensibility. 


TABLE  4- HI. 

CONTENT  GENERATION  REQUIREMENTS 

Function/Subfunction 

Functional  Requirements 

Content  Generation 

• Capability  to  develop  MOTD  using  all  type  of  presentation 
techniques 

- FOMM 

- JPA 

- Conventional  (Full  military  specification  and  modified) 

- Work  Package 

- Commercial 

- All  others  identified  by  User-Data  Match 

• Capability  to  deliver  MOTD  within  contractual  time 
constraints 

• Capability  to  develop  MOTD  within  established  performance 
measures  such  as  manhours  per  page  unit  constraints  based 
on  the  following: 

- Presentation  Techniques  (FOMM,  JPA,  etc. ) 

- System /Equipment  Types  and  Complexity  (Electronic, 
Mechanical,  etc.) 

-MOTD  Category  (Theory  of  Operation,  Troubleshooting, 
etc. ) 

- MOTD  Types  (Narrative,  Procedural,  Graphics) 

• Capability  to  develop  MOTD  compatible  with  SYSCOM  unique 
requirements 

— MOTD  Guidelines  (Specifications,  Standards) 

— System/Equipment  Types 

— Maintenance  and  Operating  Environment 

— User  Characteristics 

— Media  (Paper,  Microform,  etc.) 

• Personnel  Qualifications  - Prime  Contractor,  Equipment 
Subcontractor,  Data  Houses 

— Formal  Education  (College,  Trade  School,  Militarv 
School,  etc.) 

- Experience  (Hardware  Related,  MOTD  Related,  etc.  i 

• Capability  to  develop  and  maintain  TM  presentation  Tech- 
niques Handbooks  and  Writer's  Guides  on  Readability 
Comprehensibility  (Text  and  Graphics) 

• Compatible  with  and  able  to  evolve  from  current  contrac- 
tor and  SYSCOM  in-house  activities  with  configuration  flex- 
ibility to  account  for  contractor  differences  in  size  and 
methods  of  conducting  content  generation  activities 
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TABLE  4-in.  CONTENT  GENERATION  REQUIREMENTS  (Continued) 


F un  c Uon/Subf  unc  tion 


Content  Generation 
(Continued) 


Functional  Requirements 

Provide  quality  assurance  (in-process  monitoring  and  final 
product  review)  which  shall  use  developed  tools  (formulas, 
checklists,  statistical  sampling  techniques,  etc.  > to  insure 
MOTD  compliance  with  established  requirements 

— Limit  Technical  inaccuracies  ;uid  grammatical  inaccu- 
racies to  required  levels 

— Determine  compliance  with  requirements  for  complete- 
ness, consistency,  level  of  detail,  adherence  to  data 
acquisition  rules,  readability,  comprehensibility,  pre- 
sentation technique,  format,  organization,  and  ease  of 
access 


j • MOTD  requirements  based  on  consideration  of  the  following: 
— Criticality  of  Task 

- Complexity  of  Task 

— Frequency  of  Task  Performance 
— Impact  on  safety  to  personnel  or  equipment 
— Cost  of  Equipment 
— Maintenance  Philosophy 

- Media 

- Type  of  MOTD  (Theory  of  Operation,  Procedural  Data, 
General  Information,  IPB,  etc. ) 

• Capability  to  provide  system  level  coverage  and  system/ 
equipment  interface  data  where  inadequately  addressed  in 
existing  MOTD 

Enginee ringAlanufacturing  • Military  contractors  hardware  data  base  in  accordance  with 
Data  Base  I engineering  drawing  specification  MIL-D-1000A  and  standard 

MIL-STD-100B 

j • Military  contractor  software  data  base  in  accordance  with 
specified  Navy  guidelines  (SECNAVINST  35f><).  1,  \VS-850fi, 
DIDS,  etc.) 


• Commercial  contractor  data  bases  compatible  with  develop- 
ment of  MOTD  to  specification  MIL-M-7298C  (Commercial 
Manuals ) 


Prewriting 


• Currency  and  accuracy  maintained  via  continual  update  and 
release  of  formal  engineering  change  documents 

• Time  phasing  of  data  base  development  compatible  with 
MOTD  development  cycle 

• MOTD  proposal  responsive  to  RFP  and  also  to  include  in- 
novative alternative  MOTD  approaches,  if  required 

• Accurate  MO  TO  cost  estimate  based  on  sufficient  data 
(engineering)  manufacturing  data  base,  maintenance  philos- 
ophy, MOTD  requirements,  requirements  of  other 
support  activities) 
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TABLE  4-III. 

Function./  Subfunction 

Prewriting 

(Continued) 


Writing 


Postwriting 


TM  Presentation 
Techniques  Handbooks 


Writer's  Guides  On 
Readability/ 
Comprehensibility 
(Text  and  Graphic) 


CONTENT  GENERATION  REQUIREMENTS  (Continued)  

Functional  Requirements 

• MOTD  design  disclosure  and  planning  documents  fully  de- 
tailed and  customized  to  particular  systems/equipment 
based  on  Content  Generator  interface  with  training,  main- 
tenance engineering,  provisioning,  and  design  engineering. 

• Content  Generator  interface  with  Content  Capture 

• Capability  to  avoid  MOTD  redundancies  and  perform  head 
data/training  trade-off  based  on  Content  Generator  inter- 
face with  training  and  maintenance  engineering 

• Development  of  procedural  data  using  actual  hardware  to  be 
deployed  in  field 

• Selection  of  writers  based  on  match  of  writers  capabilities/ 
experience  and  task 

• Capability  to  interface  with  design  engineers 

• Adherence  to  validation/ verification  guidelines 

• Capability  to  develop  MOTD  in  compliance  with  data  acqui- 
sition contractual  requirements  (CDRL's,  DID's,  TMCR's, 
specifications,  standards) 

• Capability  to  manage  and  monitor  development  of  MOTD  In- 
subcontractors and  equipment  vendors 

• Capability  to  conduct  I PR's 

• Accumulate  detailed  MOTD  development  cost  data 

• Capability  to  develop  MOTD  updates  in  compliance  with 
data  acquisition  contractual  requirements  (CDRL's,  DID's, 
TMCR's  specifications,  standards) 

• Compile  program  historical  data  (cost,  problems  — 
solutions,  innovative  presentation  techniques  and  manage- 
ment approaches) 

• Capability-  to  respond  to  user  comments 

• Detailed  pi’oeedures  for  the  development  of  all  presentation 
techniques  required  by  Navy  SYSCOM's 

• Samples  of  all  presentation  techniques  required  bv  Navy 
SYSCOM's 

• Formulas,  guidelines,  and  statistical  sampling  techniques 

to  measure  readability /comprehensibility  of  text  and  graphics 

• Vocabulary  lists 
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4.4.  CONTENT  CAPTURE  REQUIREMENTS 


Requirements  for  content  capture  must  present  the  directions  to  define  those  func- 
tional elements  of  the  baseline  and  alternatives  structured  for  internal  and  external 
interfaces  ant!  standards,  and  accommodate  the  problem  areas  that  face  this  re 
search  issue. 

The  long-range  goal  of  this  issue  is  to  provide  a content  capture  function 
for  the  Navy  that  can  accommodate  the  output  of  the  contractors,  perform  update 
from  a central  publications  data  bank,  input  and  update  internal  publi cations 
using  the  same  data  bank,  and  output  for  all  media  (as  determined!.  Also,  it 
must  communicate  the  content,  manage  it,  and  be  consistent  and  common 
throughout  the  SYSCOMs.  This  is  not  an  insurmountable  task  — the  elements  that 
exist  have  functional  compatibility,  and  the  organizations  are  not  resistant  to 
the  approach. 

Content  capture  requirements  address  several  problem  areas  uncovered 
in  the  survey  of  current  and  proposed  technical  manual  systems.  These  include 
the  differences  among  SYSCOMs  in  their  automation,  or  lack  of  it;  the  related 
factor  of  no  common  standards;  the  use  of  different  media;  the  aim  of  working 
toward  performing  all  update  (after  initial  issue)  from  a publications  data  bank, 
and  the  time  required  to  move  from  an  agreed-upon  concept  through  approval 
and  funding  cycles  to  implementation.  The  requirements  are  structured  so  all 
of  these  problems  can  be  addressed  as  the  requirements  take  form  in  the  initial 
baseline  and  alternatives,  and  they  will  be  further  refined  during  the  tradeoff 
and  cost/effectiveness  analysis. 

In  the  list  of  problem  areas,  the  more  urgent  of  these  is  the  need  for  the 
SYSCOMs  to  agree  on  some  degree  of  commonality  in  their  automation  and 
standards,  especially  interface  standards.  Interface  standards  are  critical  if 
the  internal  automation  development  (or  improvement)  toward  a MOTD  data 
bank  concept  is  pursued.  In  particular,  the  interface  standard  between  the 
SYSCOMs  and  their  contractors  is  inquired  to  provide  cost/effective  methods 
to  simplify  data  flow  from  one  contractor  to  more  than  one  SYSCOM,  and  easy 
SYSCOM-to-SYSCOM  exchange  of  contractor  MOTD.  Common  standards  can 
provide,  to  those  still  not  automated,  or  ready  to  further  sophisticate,  a guide 
for  directing  their  efforts  toward  a compatible  system.  Looking  ahead,  since 
the  Army  and  Air  Force  are  not  as  yet  committed  to  an  automation  interface  to 
contractors,  the  Navy  can  provide  the  leadership  in  the  field  of  automation  as  it 
relates  to  this  facet  of  MOTD  processing. 

The  use  of  different  media  is  a problem  being  compounded  by  unilateral 
actions  in  the  SYSCOMs  of  pursuing  separate  media  development  programs.  The 
previously  stated-requirement  for  a Media  Laboratory  may  be  a solution  to  this 
problem.  Although  not  a positive  assurance  that  a medium  will  not  be  recom- 
mended that  turns  out  to  be  ineffective,  with  a common  media  laboratory  it  is 
greatly  minimized.  More  important,  however,  is  the  capability  (within  such 
a Laboratory)  to  assess  and  test  a medium  for  its  inherent  attributes  (or  lack 
of  them)  and  then,  if  warranted,  apply  that  medium  to  all  environmental  or  use 
situations  using  controlled  and  objective  means.  Being  able  to  forecast  media 
development  could  prevent  costly  excursions  into  what  may  turn  out  to  be 
"short-term’'  media  programs.  Media  standardization  is  part  of  the  means, 
and  media  forecasting  is  an  additional  part,  for  the  Navy  to  continually  provide 
the  user  with  MOTD  in  its  most  usable  form. 
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Working  toward  the  development  of  capabilities  to  perform  all  update 
will  be  affected  by  the  progress  in  development  of  standards,  automation  inter- 
faces and  conformance  by  the  contractors.  The  recent  position  paper  relative 
to  the  threat  of  the  NAVAIR  Technical  Review  and  Update  of  Manuals  and 
Publications  (TRUMP)  system  to  contractors  update  of  MOTD  for  in-production 
equipment  issued  by  Aerospace  Industries  Association  (A1A)1  will  also  have  to 
be  considered  as  this  requirement  is  defined  in  functional  terms  and  synthesized 
in  subsequent  NT1PP  tasks.  Basically,  whether  the  SYSCOMs  perform  all  or 
only  some  of  the  updates,  the  automation  interface  is  still  a future  requirement 
needed  to  support  an  MOTD  data  bank  of  in-production,  out-of-production,  or 
both  categories  of  equipment. 

The  problem  of  the  time  needed  to  take  the  system  design  of  a concept 
through  the  various  approval  cycles  and  then  obtain  funding  has  both  positive  and 
negative  aspects.  Time  may  be  an  ally  if  emerging  technology  can  be  qualified 
early  as  a viable  approach,  such  as  video  disc  or  holograms  as  media,  or 
satellite  communications  for  MOTD  delivery.  Time  permits  refinement  of  such 
development  with  subsequent  improvement  in  cost/effectiveness  during  approval 
and  funding  cycles,  and  before  implementation.  On  the  other  hand,  if  sufficient 
foresight  is  not  applied  to  the  selection  process,  when  it  is  time  for  implemen- 
tation the  selection  may  be  out-of-date.  There  is  a tendency  to  design  in  a "tried 
and  true"  state-of-the-art  mode  without  considering  that,  potentially,  there  can 
tie  a several-year  cycle  before  design  becomes  reality.  Although  NTIPP  might 
use  the  time  factor  to  advantage,  concentration  is  still  required  on  overall  im- 
provement to  the  approval/funding  cycles.  One  area  that  needs  to  be  assessed  is 
the  method  of  (or  need  for)  obtaining  approvals  from  other  agencies  sucli  as  die 
Joint  Committee  on  Printing  for  "composition"  equipment  or  the  data  processing 
organizations  for  "computer"  equipment.  Regardless  of  the  attributes  that  are 
rationalized,  the  time  from  conception  to  implementation  is  too  long.  This  pro- 
blem area  does  not  pertain  only  to  the  Content  Capture  issue. 

There  is  a basic  requirement  of  NTIPP  to  develop  from  existing  capability 
within  the  Navy,  providing  it  is  cost/effective.  Although  not  stated  per  se,  the 
requirement  to  accommodate  the  NAVSEA  Automated  Documentation  Preparation 
System  (ADPREPS)  and  the  NAVAIR  TRUMP  system  now  in  use  and  in  an  upgrade 
mode  is  assumed  and  included.  Specific  functional  parameters  for  these  systems 
in  relation  to  the  NTIPP  Content  Capture  of  the  1980's  will  be  considered  in 
preparation  of  the  baseline  or  alternatives  in  Task  3. 

Table  4-1V  lists  the  requirements,  generally  defined,  that  are  needed  to 
provide  the  functional  elements  both  to  work  problem  areas  and  to  provide  the 
means  to  serve  the  Content  Caputre  needs.  They  reflect  not  only  the  analysis 
of  current  and  proposed  TM  systems  and  the  resulting  postulations,  but  they 
embody  the  thoughts  and  expressions  of  many  with  whom  NTIPP  research  inter- 
faced. Although  broadly  stated,  the  list  provides  the  basis  to  develop  the  base- 
line and  alternatives.  Examples  of  means  to  meet  stated  requirements  are  pro- 
vided for  clarity.  During  the  further  baselining  and  the  subsequent  tradeoff  and 
cost-effectiveness  analysis  the  functional  entities  vail  be  narrowed  and  the  se- 
lected NTIPP  Content  Capture  of  the  1980's  will  be  defined. 


' PUBS- 100  Panel,  "Navy  TRUMP  System  Activation  Circumvents  OMBA-7G," 
Aerospace  Industries  Association,  October  197G. 
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tion  4 — Research  Issue  Level  NTIPP  Requirements 


4.4.  CONTENT  CAPTURE  REQUIREMENTS  (Continued) 


TABLE  4-IV.  CONTE  NT  CAPT  URE  REQUIREMENTS 

A.  Content  Capture  Requirements  Involving  Interfaces  Internal  to  the  Issue: 

1.  To  provide  a netted,  centrally  controlled,  localized  structure  of 
SYSCOM's  publications  capability  with  common  standards,  policies 
and  procedures. 

2.  To  provide  (where  possible),  the  ability  to: 

a.  Enter  text  and  tabular  material  interactively  in  an  automated 
system  using  such  devices  as  a Visual  Display  Terminal  (VDT) 
or  standard  keyboard  terminal. 

b.  Enter  text  and  tabular  material  in  a batch  mode  in  an  automated 
system  using  such  devices  as  OCR  or  digital  readers  (tape, 
cassette,  cartridge,  diskette,  paper). 

c.  Enter  graphic  material  interactively  in  an  automated  system 
using  such  devices  as  VDT,  digitizer,  and  program  function 
keyboard  tablet. 

d.  Enter  graphic  material  in  a batch  mode  (intelligent  form)  on 
an  automated  system  using  such  devices  as  digital  scanners. 

e.  Edit,  update,  and  format  text,  tabular  and  graphic  material  in 
an  interactive  mode  using  such  devices  as  visual  display 
terminals  in  an  automated  system  with  such  features  as: 

• Global  locate  and  replace,  delete,  add,  move,  sort, 
and  other  change  and  process  actions. 

• Measurement  of  readability  and/or  comprehensivility 
of  text  and  graphics  (as  defined). 

• Extraction  of  tables  of  contents,  lists  of  tables  and 
illustrations,  and  selected  indices. 

• Text  and  graphic  merge. 

• Selected  function  coding  for  output  media  and  digital  con- 
version method. 

f.  Store  in  working  storage  media  such  as  disc  or  diskette, 
sufficient  data  to  meet  work-in-process  needs. 

g.  Output  in  digital  form,  the  structured  MOTD  for  conversion  into 
media  such  as,  hardcopy,  microfilm,  video  disc,  or  holograms. 

h.  Accumulate  and  report  management  information  such  as  amounts 
and  types  of  data  being  input,  output,  processed  and  stored; 
operating  time  and  down  time;  and  other  machine,  manpower, 
material,  and  related  cost  data. 

i.  Prepare  text,  tabular,  and  graphics  using  conventional  means 
(interim). 

j.  Prepare  audio/video  media  using  such  devices  as  television 
cameras  and  recorders,  photographic  cameras  and  processors, 
and  audio  recorders  and  players  - (as  determined). 


TABLE  4- IV.  CONTENT  CAPTURE  REQUIREMENTS  (Continued) 

B.  Content  Capture  Requirements  Involving  Interfaces  to  External  Functional 
Entities: 

1.  To  provide  the  ability  to  accept  from  contractors  such  input  as: 

a.  Text  material  in  digital  form  (with  and  without  graphics)  on 
magnetic  tape  (reel,  cassette,  cartridge),  diskette,  paper 
tape,  as  repro  copy  (with  and  without  graphics),  or  copy 
prepared  for  optical  character  recognition  (OCR). 

b.  Graphic  material  in  digital  form  (image  or  intelligent  separate 
from  text)  on  magnetic  tape  (reel  or  diskette),  as  repro  art, 
or  original  artwork.  (Also  graphics  integrated  with  text  - 
see  above. ) 

2.  To  develop  program  to  assist  contractors  to  convert  to  meet 
standards  (from  B-l,  above). 

3.  Store  in  archrival  storage  media  such  as  high  density  tape  or 
solid  state  methods,  the  inventory  of  publications  under  local 
control. 

4.  Convert  digital  output  into  such  media  as  repro  copy,  microform 
master,  printing  plate,  video  disc  master,  or  hologram  master 
using  such  devices  as  computer  output  microform,  photocomposi- 
tion, video  disc  and  hologram  mastering  equipment.  (Relates  to 
Replication  function. ) 

5.  Communicate  among  central,  localized,  and  user  facilities,  using 
such  methods  as  mail,  landline  and  wireless,  the  MOTD  received 
by  and  created  in  NTrPP  content  capture.  (Relates  to  the 
distribution  function. ) 

6.  To  provide  a controlled  and  compatible  (to  internal)  structure 
of  subcontractor  capability  in  content  capture  functions  such  as, 
text  and  tabular  processing,  graphics  processing,  and  digital 
conversion  to  media  masters. 

7.  Provide  a continuing  technological  assessment  operation  in 
content  capture  related  disciplines  such  as  text  and  graphic 
processing,  media  conversion,  communications,  computers, 
and  mass  storage.  (Part  of  Media  Laboratory  requirement. ) 

C.  Content  Capture  Requirements  Involving  Standards: 

1.  To  develop  standards  of  input  for  the  above,  such  as 

Digital  code 
Digital  data  format 
OCR  input  format 
Digital  Media 

Note:  Other  form  and  format  requirements  are  controlled  by 
specification  and  contract  requirements. 

2.  Provide  quality  assurance  of  products  and  processes  through 
quality  control  structure  such  as  text  proofreading,  art  cheeking, 
and  product  inspection. 
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Section  4 - Research  Issue  Level  NTIPP  Requirements 


4.5  CONTENT  REPLICATION  REQUIREMENTS 


Requirements  for  this  issue  must  provide  the  direction  to  define  the  functional 
elements  needed  to  perform  required  replication  in  the  1980's  considering  media 
changes,  interfaces,  transitional  problems,  standards,  and  other  developmental 
concerns. 

The  requirements  for  the  post-1980 replication  issue  must  accommodate 
both  the  existing  and  the  emerging  methods  of  developing  and  delivering  MOTD. 
There  are  present  functions  that  become  interim  in  the  long-range  scheme  of 
NTIPP  replication.  As  the  media  change,  and  as  replication  becomes  more  on- 
site/on-demand, the  requirements  lessen  to  provide  replication  at  or  near  the 
point  of  content  capture. 

The  overall  goal  of  the  replication  issue  is  to  provide  the  functions  to 
take  the  output  of  a central  publications  data  bank  (of  content  capture)  convert 
it,  replicate  it  in  various  media  (as  determined),  communicate  it,  and  manage 
it.  This  task  does  not  have  some  of  the  problems  of  other  NTIPP  issues  such 
as  standardization  among  SYSCOM's,  as  a centralized  Navy  organizational/ 
functional  structure  exists  that  can  accommodate  the  conceptualization  of  the 
NTIPP  replication  requirements.  However,  there  are  several  areas  of  concern. 

Among  these  areas  of  concern  are  the  extensive  use  of  subcontractors 
for  replication  services,  the  media  impact  and  use  of  different  media,  the  need 
for  standards  for  new  technology,  the  need  for  automation  of  functional  elements, 
and  the  evolution  from  conventional  replication  to  new  concepts.  These  factors 
have  been  considered  in  the  preparation  of  the  general  requirements  so  that 
their  impact  can  be  further  assessed  and  accommodated  as  needed  as  the  base- 
line and  alternatives  are  defined. 

Of  primary  concern  to  NTIPP  replication  is  media  selection.  Since  there 
are  several  potential  media  which  likely  will  be  narrowed  down  to  one  or  two  as 
NTIPP  evolves,  the  functional  requirements  will  also  narrow.  But  even  if  a 
new  medium  such  as  video  disc  is  determined  to  be  the  most  effective,  with  the 
protracted  time  (a  minimum  of  five  years)  to  make  the  transition,  conventionally 
printed  manuals  and  microforms  will  still  need  to  be  supported  in  the  early 
1980's.  Therefore,  the  narrowing  process  and  transition  dictates  the  require- 
ment to  continue  to  provide  functional  capability  for  the  present  media  (printed 
books  and  microforms)  in  the  interim.  There  is  a likelihood  that  microfiche, 
just  now  being  implemented  in  NAVSEA  and  NAYELEX  (and  for  some  MOTD 
applications  by  NAVAIR)  could  be  in  use  well  beyond  1980.  If  so,  the  NTIPP 
structure  must  accommodate  the  functional  need  and,  therefore,  a requirement 
is  herein  stated  to  cover  this  likelihood. 

The  use  of  subcontractors  to  provide  most  of  the  actual  replication 
services  (nearly  lOOYf  of  printed  MOTD)  is  another  area  of  concern.  If  on-site/ 
on-demand  replication  from  digital  media  becomes  a principal  NTIPP  method, 
the  use  of  the  existing  structure  of  printers  and  micropublishers  will  decline. 
Replication  of  some  digital/optic  media  will  be  needed  with  such  potentially 
acceptable  media  as  video  disc  or  holograms,  but  the  replication  methods  are 
relatively  inexpensive  (compared  to  printing)  and  attendent  costs  will  reduce 
significantly.  Since  today's  heavy  use  of  subcontractors  is  not  by  choice  - 
the  Congressionsal  Joint  Committee  on  Printing  (JCP)  has  "encouraged"  use 
of  commercial  replication  — the  transition  to  new  media  replication  will  have 
to  consider  this  factor.  One  potential  approach,  going  directly  to  the  user 
locale  with  the  digital  output  of  content  capture  via  a communications  channel, 
would  essentially  eliminate  the  need  for  delivery  media.  This  would  also  elimi- 
nate the  need  for  a replication  middleman  (the  subcontractor).  In  this  case,  the 
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need  for  replication  would  still  exist,  but  at  the  user's  locale  to  provide  the 
media  the  user  would  need  to  perform  his  assigned  tasks.  Other  approaches 
would  still  need  a replication  middleman,  but  at  best  the  role  of  die  subcontractor 
t will  change  in  die  future  NTIPP. 

Any  redirection  of  replication  into  areas  with  computer  (or  automation) 
disciplines  will  need  the  benefit  of  standards  and  controls.  Unlike  the  Content 
Capture  issue,  where  automation  to  different  standards  lias  proliferated  (inter- 
nal to  the  Navy  and  external  with  contractors),  the  replication  issue  has  the 
opportunity  to  start  in  control.  Again,  the  key  standards  apply  to  interfaces. 
Should  conversion  from  content  capture  digital  output  be  performed  on  devices 
(such  as  computer  output  microform  or  photocomposition)  under  control  of  all 
replication  organizational  entities,  the  digital  interfaces  need  to  lie  compatible. 
Further,  if  the  use  of  subcontractors  continues  into  the  future  where  replication 
may  be  in  a digital  media  environment,  standards  then  need  to  be  applied  to  that 
interface  also.  Gnerally,  in  as  much  as  automation  will  impact  several  areas 
of  NTIPP  (Content  capture,  distribution,  feedback,  system  management)  it  be- 
comes a co-requirement  among  the  issues  to  provide  a means  toward  providing 
consistant  automation  standards. 

Also  impacting  replication  requirements  is  the  overriding  control  struc- 
ture of  the  JCP  and  the  Government  Printing  Office  (GPO),  and  their  charters  in 
relation  to  the  charters  of  the  Navy  Publications  and  Printing  Services  Office 
(NPPSO)  and  NAVSUP,  the  NPPSO  parent  organization.  The  charters  are  well 
defined,  the  control  mechanisms  well  formed,  but  they  appear  to  be  somewhat 
rigid  and  inhibiting  (to  change)  looking  from  the  outside.  Further,  within  the 
structure,  some  unilateral  actions  impacting  NTIPP,  such  as  recently  announced 
NAVSUP  R&D  efforts  in  media  technology,  have  been  evident.  These,  although 
not  counter  to,  can  be  duplicative  to  other  NTIPP  efforts.  Since  presently  and 
in  the  future,  cognizance  for  replication  rests  with  NPPSO/GPO/JCP  the  require- 
ment is  to  work  this  structure  into  the  total  NTIPP  so  it  is  responsive  to  the 
needs  of  NTIPP  and  the  user  community. 

There  is  an  overriding  concern  as  NTEPP  evolves  from  conventional  media 
use  and  its  replication  into  new  concepts.  The  concern  is  more  than  just  die 
time  of  the  evolutionary  process  and  the  need  to  accommodate  new  and  old  media 
in  an  interim  period.  The  replication  functions  now  performing  MOTD  replica- 
tion are  comprised  or  organizations  with  established  roles  in  the  replication 
scheme.  There  are  policies,  procedures,  and  charters,  as  well  as  people  and 
machinery  and  all  the  related  costs  to  operate.  As  with  the  subcontractor's  sit- 
uation discussed  above,  the  total  role  may  change.  When  defined  for  the  future, 
the  new  role  would  impact  some  or  all  of  the  cited  factors.  If  so,  then  the  factors 
of  procedure,  equipment,  personnel,  and  most  of  all  cost,  come  into  play  in  the 
development  and  analysis  of  a baseline  and  alternatives.  Substantiation  of  gross 
changes,  particularly  if  a multi-million  dollar  investment  is  to  be  discarded  be- 
fore it  approaches  realistic  amortization,  can  be  most  difficult  and  represents  a 
challenge  for  tradeoff  and  cost/effectiveness  analysis. 

The  requirements  that  are  needed  to  provide  the  functional  elements  both 
to  accommodate  the  areas  of  concern  and  to  provide  the  means  to  serve  the  re- 
plication needs  are  presented  in  Table  4-V.  As  with  other  NTIPP  issues,  they 
. reflect  the  analysis  of  current  and  proposed  TM  systems,  and  the  thoughts  and 

i expressions  of  many  with  whom  NTIPP  research  interfaced. 

The  list  of  requirements  here  is  also  broadly  stated  and  contains  items  to 
I support  the  interim  multi-media  situation  NTIPP  must  face.  Media  defined  for 

& the  user  is  but  one  facet  of  the  problem.  The  potential  for  content  to  be  captured 

* 
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4.  5 CONTENT  REPLICATION  REQUIREMENTS  (Continued) 


in  one  medium,  stored  in  a second,  transmitted  in  a third,  and  converted  for  use 
in  still  a different  medium  compounds  the  media  question,  particularly  in  the 
on-site  on-demand  approach  to  replication.  Further,  because  cliange  and  conver- 
sion is  likely  to  be  slow,  some  media  will  remain  in  the  system  for  a while  even 
though  it  is  being  replaced.  The  refinement  of  the  baseline  alternatives  in  o flier 
research  issues  will  identify  media  for  the  varied  uses  and  consequently  will 
permit  the  tradeoff  and  cost/effectiveness  analysis  to  select  the  replication  func- 
tional entities  for  NTIPP  to  accommodate  those  chosen. 


TABLE  4-V.  REPLICATION  REQUIREMENTS  _ 

A.  Replication  Requirements  Involving  Interfaces  Internal  to  the  Issue: 

1.  To  have  a centrally  controlled  organizational/functional  structure 
for  replication  to  include  on-demand  requirements. 

2.  To  provide  the  mechanisms  to  refine  replication  standards,  policies, 
and  procedures  to  meet  total  NTIPP  requirements  as  defined. 

3.  To  provide  (as  determined  for  NTIPP)  replication  ability  to: 

a.  Convert  digital  MOTD  to  media  selected  for  use  such  as  paper, 
microform,  or  visual  display,  routinely  and  on-demand  in  user 
locals  (as  determined). 

b.  Convert  digital  input  into  media  such  as  microform  masters, 
printing  masters  (plates),  video  disc  masters , or  hologram  masters 
using  such  devices  as  computer  output  microforms,  photocomposi- 
tion, video  disc  and  hologram  mastering  equipment.  (Relates  to 
Content  Capture  function). 

c.  Convert  microform,  repro  copy,  and  lithographic  negatives  to 
printing  plates  using  conventional  contact  and  projection  photo- 
graphic/imaging means. 

d.  Replicate  in  paper  media  from  the  above,  collate,  and  bind  using 
such  conventional  devices  as  printing  presses,  collaters,  stitchers, 
etc. 

e.  Convert  repro  copy  to  microform  masters  using  conventional 
photographic  means. 

f.  Replicate  from  microform  masters  using  such  methods  as  silver 
halide,  diazo,  and  vesicular. 

g.  Relicate  from  digital-form  masters  such  as  video  disc  or  hologram 
masters  using  such  methods  as  disc  pressing  or  film  duplicating 
methods  of  silver  halide,  diazo,  and  vesicular. 

4.  Accumulate  and  report  management  information  such  as  amounts  and 
types  of  data  being  replicated,  and  other  machine,  manpower,  material, 
and  related  cost  data. 


TABLE  4-V.  REPLICATION  REQUIREMENTS  (Continued) 


B.  Replication  Requirements  Involving  Interfaces  to  External  Functional 
Entities: 

1.  To  provide  the  ability  to  accept  from  contractor  or  internal  content 
capture  functions  such  input  as: 

a.  MOTD  created  as  repro  copy, 

b.  Lithographic  negative  or  printing  plates, 

c.  Microform  masters,  fiche  or  roll  and 

d.  Digital  form  masters  such  as  tape,  diskette,  video  disc,  hologram, 
etc.  (to  be  determined). 

2.  To  develop  program  to  assist  contractors  to  convert  to  meet  standards 
(from  2,  above). 

3.  To  broaden  replication  control  mechanisms  to  accomodate  digital/optic 
media  delivery  and  conversion. 

4.  Communicate  the  MOTD  received  by  and  processed  in  NTIPP  replication 
among  central,  localized,  and  user  facilities,  using  such  methods  as 
mail,  landline,  and  wireless.  (Relates  to  distribution  function. ) 

5.  To  provide  a controlled  and  compatible  (with  internal)  structure  of  sub- 
contractor capability  in  replication  functions  such  as  conventional  paper 
media  printing,  microform  processing,  digital  conversion  to  digital 
media  masters,  and  their  duplication. 

6.  Provide  a continuing  technological  assessment  in  replication  disciplines 
such  as  media  conversion,  media  reproduction,  and  automation  of 
replication  entities  (Part  of  Media  Laboratory  requirement). 

C.  Replication  Requirements  Involving  Standards. 

1.  To  assist  in  development  of  standards  for  digital  data  such  as: 

a.  Digital  Code 

b.  Digital  data  format 

c.  Digital  media 

NOTE:  Other  form  and  format  requirements  are  controlled  by 

specification  and  contract  requirements) 

(See  Content  Capture  Requirements) 

2.  Provide  quality  assurance  of  products  and  processes  through  a quality 
control  structure  such  as  in-process  and  final  product  inspection. 
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Section  4 — Research  Issue  Level  NTIPP  Requirements 


4.  fi.  DISTRIBUTION  REQUIREMENTS 


Requirements  of  distribution  are  primarily  to  deliver  MOTD  to  the  user  utilizing  the 
most  efficient,  cost-effective  methods,  maintain  an  up-to-date  MOTD  configuration 
index  of  all  users,  and  provide  a vehicle  to  expedite  the  delivery  of  all  Feedback  Re- 
ports (FBRs)  and  FBR  responses  between  the  user  and  the  SYSCOMS. 

Distribution  requirements  must  address  certain  problems  uncovered  dur- 
ing the  study  of  the  present  and  proposed  distribution  systems.  These  include  the 
lack  of  a centrally  controlled  distribution  and  storage  system,  the  lack  of  a user 
MOTD  coordinator,  the  existence  of  a multitude  of  storage  points  for  MOTD,  and 
a need  for  an  up-to-date  MOTD  configuration  index  for  each  user. 

The  ultimate  requirement  is  to  provide  a distribution  system  and  a stor- 
age system  that  will  be  controlled  with  storage  facilities  strategically  situated  to 
provide  rapid  delivery  and  good  availability  to  the  user.  The  distribution  system 
will  respond  to  the  number  and  type  of  MOTD  required  by  the  user,  deliver  the 
MOTD  at  the  desired  time,  establish  controls  of  distribution  from  a continuing 
system  evaluation,  and  utilize  the  most  cost-effective,  timely  methods  of  distri- 
bution. The  storage  system  will  have  an  active  and  inactive  multimedia  storage 
capability  that  will  use  a MOTD  index  numbering  system  common  to  all  SYSCOMs. 

The  present  system  divides  the  MOTD  distribution  responsibilities  be- 
tween two  separate  organizations  - the  SYSCOMs  and  NAVSUP  (Navy  Supply). 
During  equipment  acquisition,  the  SYSCOM  Program  Manager  provides  a distri- 
bution list  to  NPPSO  (Navy  Publications  and  Printing  Services  Office)  for  delivery 
to  the  user.  All  extra  bulk  copies  are  stored  at  NPFC  (Navy  Publication  and 
Forms  Center)  to  await  any  replenishment  requests  from  the  user  via  the 
NAVSUP  route.  One  proposed  distribution  system  being  studied  is  totally  depend- 
ent on  the  use  of  new  digital  media  for  replication  at  the  user  or  storage  site,  but 
the  split  responsibility  of  distribution  will  still  be  retained. 

The  requirement  for  a centrally  managed  distribution  system  would  alle- 
viate the  split-responsibility  problem  and  establish  a control  point  to  continually 
be  responsible  for  the  distribution  process.  The  requirements  for  the  distribu- 
tion system  will  provide  for  a continual  evaluation  of  the  user's  MOTD  needs 
(both  initial  and  replenishment);  a verification  of  distribution  of  MOTD  to  the 
user;  a control  and  evaluation  of  each  facet  of  the  distribution  cycle;  and  the 
proper  utilization  of  the  most  expeditious,  cost-effective  distribution  methods. 

The  distribution  system  will  be  further  enhanced  by  the  requirement  for 
maintaining  an  up-to-date  MOTD  configuration  index  for  each  user,  plus  the  peri- 
odic distribution  of  a configuration  report  to  each  user.  This  MOTD  configura- 
tion index  will  assist  in  evaluating  the  user  MOTD  needs,  and  can  also  be  used 
by  the  user  as  a checklist  against  the  delivered  MOTD. 

Control  and  evaluation  of  the  distribution  system  and  storage  system  will 
be  accomplished  by  the  requirement  for  periodic  MOTD  status  reports.  The 
status  reports  will  provide  the  total  amount  of  MOTD  distributed  and  the  total 
amount  required  to  restock  the  storage  facilities  to  proper  levels.  The  informa- 
tion in  the  status  reports  will  be  used  to  establish  and  maintain  proper  MOTD 
storage  levels  to  accommodate  user  replenishment  requirements. 

As  user  FBRs  will  be  the  prime  interfacing  instrument  between  the  user 
and  the  SYSCOMs,  a controlled  FBR  delivery  vehicle  between  the  two  is  a "must" 
requirement.  The  requirement  will  establish  a system  to  control  and  track  the 
FBR  from  the  time  it  leaves  the  user  work  area  until  the  delivery  of  the  FBR 
response  back  to  the  user  work  area.  Any  portion  of  the  cycle  that  slows  the 
resolution  of  the  FBR  will  be  exposed  and  reported. 


The  user  MOTD  coordinator  requirement  will  provide  control  of  the  MOTD 
after  delivery.  The  coordinator  will  verify  delivery  to  the  proper  work  center, 
and  will  be  responsible  for  all  outgoing  FBRs  and  incoming  FBR  responses. 

The  primary  storage  center  for  all  bulk  copies  of  MOTD  is  now  NPFC  - 
part  of  a system  which,  historically,  has  been  slow  in  reacting  to  MOTD  requests 
from  the  user.  A requirement  exists  for  a centrally  controlled  distribution  center 
which  will  provide  a more  responsive,  available  system. 

The  centralized  storage  system  will  contain  an  active  and  an  inactive  data 
bank,  and  will  utilize  a MOTD  index  numbering  system  common  to  all  SYSCOMs. 

The. active  storage  data  bank  will  pertain  to  deployed  operational  systems,  and 
will  be  maintained  in  hard  copy,  digital,  and  microform  media.  The  inactive 
storage  data  bank  will  be  historical  data  on  unused  systems,  and  will  be  main- 
tained in  media  determined  to  be  most  cost-effective. 

The  present  method  of  restocking  MOTD  at  NPFC  is  to  wait  for  depletion 
of  bulk  copies,  and  then  request  NPSSO  to  order  a large  quantity  of  hard-copy 
manuals.  Delays  in  deliveries  of  MOTD  will  be  removed  as  the  publishing  media 
of  future  MOTD  tends  toward  digital  media  and  on-demand  replication.  The  use 
of  digital  media  will  allow  the  storage  system  to  replicate  any  number  of  copies, 
or  to  send  a master  copy  to  the  user  for  his  replication. 

TABLE  4-VI.  DISTRIBUTION  REQUIREMENTS 

1.  Provide  a centrally  managed  system  to  distribute  MOTD  from  strategically  located 

points  that  will: 

a.  Evaluate  user  MOTD  requirements, 

b.  Distribute  MOTD  to  the  user, 

c.  Control  all  facets  of  the  distribution  cycle,  and 

d.  Utilize  the  most  efficient,  cost-effective  distribution  methods. 

2.  Maintain  an  up-to-date  MOTD  configuration  index  for  each  user. 

3.  Provide  Periodic  MOTD  configuration  management  reports  to  the  user. 

4.  Provide  a controlled  vehicle  for  transferring  feedback  reports  (FBRs)  and  FBR  responses 

between  the  user  and  the  SYSCOMs. 

a.  Total  number  of  FBRs  processed, 

b.  Status  of  unresolved  FBRs, 

c.  Disposition  of  resolved  FBRs,  and 

d.  MOTD  requirements. 

5.  Provide  a user  MOTD  coordinator. 

(>.  Maintain  proper  MOTD  storage  levels  for  user  requirements, 

7.  Provide  a centrally  controlled  multimedia  storage  facility  for  both  active  and  inactive 

data  banks. 

8.  Provide  capabilities  for  replication  of  limited  quantity  MOTD  requests. 


Section  1 - Research  Issue  Level  NTIPP  Requirements 


4.  7 


UPDATE  REQUIREMENTS 


The  MOTD  update  research  issue  requirements  must  address  certain  problems 
uncovered  during  the  Task  1 effort.  These  problems  include  a lack  of  configura- 
tion control,  separate  approaches  for  automation  of  content  capture,  and  similar 
but  separate  update  functions  for  each  SYSCOM. 

The  update  issue  requirements  must  include  the  addition  of  a viable,  con- 
tinuing configuration  control  function  that  will  be  available  for  the  MOTD  update 
cycle.  The  configuration  control  function  would  provide  a list  of  the  equipment 
each  user  is  responsible  for,  the  current  change  status  of  each  equipment,  and  an 
inventory  of  the  TM  the  user  is  maintaining.  Additional  information  the  con- 
figuration control  function  could  provide  is  environmental  data  about  where  the 
MOTD  is  used  and  the  storage  area  requirements  for  the  MOTD.  The  environ- 
ment and  storage  information  could  be  utilized  to  make  a change  of  media  that 
would  be  more  compatible  to  a special  work  center  environment  or  storage 
require  ment. 

At  present,  MOTD  for  in-production  equipment  and  out-of-production 
equipment  is  updated  by  different  methods.  The  in-production  equipment  MOTD 
is  normally  updated  by  the  equipment  manufacturer,  while  the  out-of-production 
equipment  MOTD  is  the  responsibility  of  the  SYSCOM' s field  support  offices. 

The  actual  updating  of  the  out-of-production  MOTD  is  accomplished  by  the 
SYSCOM  field  support  office,  if  the  capability  exists,  or  by  sub-contracted  data 
houses.  The  update  issue  requirements  must  look  at  the  separation  of  the  updat- 
ing functions  and  find  the  most  feasible,  cost-effective  method  of  updating  the 
in-production  and  out-of-production  equipment  MOTD. 

Presently,  investigations  have  shown  that  future  media  requirements 
will  change  the  predominant  hard-copy  media  to  a digital  or  microform  media. 
There  will  still  be  a possible  need  for  hard-copy  media  to  satisfy  a specific  work 
center  envi ronment  requirements:  hence,  update  issue  requirements  must 
address  the  problem  of  MOTD  updating  in  multimedia.  Updating  could  be  accom- 
plished by  distributing  master  copies  in  digital  or  microform  media  and  pro- 
viding the  replicating  function  at  the  user  site  in  the  media  required. 

Normal  updating  occurs  only  when  a sufficient  number  of  changes  to  the 
equipment  or  the  MOTD  warrant  it.  The  update  issue  requirements  must  cover 
the  need  for  a fast-reacting  emergency  updating  function.  An  emergency 
request  will  normally  originate  with  a user  feedback  report,  and  will  reveal  a 
MOTD  related  condition  that  is  hazardous  to  personnel  or  destructive  to  the 
equipment.  Though  the  problem  will  be  answered  by  the  feedback  function,  it  is 
imperative  to  update  the  MOTD  as  soon  as  possible  to  remove  any  dangerous 
data  from  the  MOTD. 

Normally  the  primary  reason  for  MOTD  update  is  a change  in  equipment 
configuration.  At  the  same  time,  an  attempt  is  also  made  to  remove  any  noted 
data  inaccuracies  and  to  improve  any  inconsistent  presentation  methods  or  MOTD 
organization  problems.  The  update  issue  requirements  must  cover  the  possi- 
bility of  having  a continuing  updating  function  to  provide  the  most  up-to-date, 
complete  and  correct  MOTD  for  the  user. 

One  of  the  present  problems  affecting  the  updating  of  MOTD  is  the  lack 
of  funds  to  accomplish  the  task.  As  this  will  be  a continuing  problem,  the 
update  issue  requirements  must  address  the  use  of  new  media  or  automation 
methods  that  will  allow  faster-reacting  updating. 

Automation  is  being  approached  separately  by  the  SYSCOMs,  and  is 
presently  being  used  only  with  out-of-production  equipment  MOTD.  The  update 
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issue  requirements  must  verify  the  most  feasible  approach  to  automation  of 
both  in-production  equipment  and  out-of-production  equipment  MOTD. 

To  most  effectively  use  the  available  TM  fluids  allocated,  a TM  update 
priority  system  must  be  developed  and  established.  This  priority  system  will 
evaluate  the  importance  of  the  equipment-user  primary  mission,  the  population 
of  the  equipment,  the  life -expe ctancy  of  the  equipment,  and  the  urgency  of  any 
reported  discrepancy.  The  use  of  prioritization  will  allow  the  more  important 
TM's  to  be  updated  first  and  allow  more  expeditious  use  of  available  resources. 

TABLE  4-VH.  UPDATE  REQUIREMENTS 

• Provide  an  MOTD  update  system  for: 

— In  Production  Equipments 

— Out  of  Production  Equipments 
— All  Types  of  Media 
— Emergency  Requests 
— Equipment  Changes 

• Provide  an  update  system  that: 

— Is  responsive  to  the  MOTD  user 
— Reacts  to  update  need  in  a timely  maimer 

— Employs  the  most  cost-effective  methods  and  techniques  for  update 
(compatible  with  original  content  capture) 

“ Uses  automated  methods  for  processing  and  management  data 
(compatible  with  original  content  capture) 

— Has  a controlled  management  function 

— Provides  quality  assurance  (in-process  monitoring  and  final  product 
review)  which  shall  use  developed  tools  (formulas,  statistical  sampl- 
ing techniques,  etc. ) to  insure  MOTD  compliance  with  established 
requirements 

• Provides  a method  for  compiling  program  historical  data  (costs, 
problems-solutions,  innovative  presentation  teclmiques  and 
management  approaches) 

• Provides  an  MOTD  update  prioritization  system 

• Provides  a configuration  control  function  to  the  MOTD  update  system. 

NOTE : Update  requirements  generally  relate  to  and  parallel  those  of 
the  Content  Capture  Research  Issue  and  Content  Generation 
Research  Issue. 


Section  4 - Research  Issue  Level  NTIPP  Requirements 


4.8  FKL'DRACK  REQUIREMENTS 


The  feedback  requirements  must  address  both  reporting  and  information-gathering 
techniques  tied  to  centralized  and  authoritative  systems  for  communications,  analy- 
sis and  corrective  action.  Acknowledgement  to  the  reporter  (user)  is  also 
important. 

The  objective  of  the  feedback  system  is  to  provide  the  means  for  the  user 
of  MOTD  to  report  discrepancies,  and  for  the  mechanisms  to  be  provided  so  that 
the  reported  information  can  be  acted  upon.  4'he  feedback  system  must  also  pro- 
vide the  capability  to  gather  information  to  support  the  reporting  system.  The 
tendency  of  a reporting  system  is  nearly  always  to  report  the  critical  problems 
and  less  frequently  report  the  more  minor  problems.  An  information-gathering 
system  will  tend  to  uncover  the  other-than-critical  problems.  To  adequately  as- 
sess the  relative  value  of  the  MOTD,  its  accuracy  and  completeness  (usability) 
both  types  of  systems  should  be  employed.  This  is  a stated  requirement  on  the 
accompanying  list  of  requirements. 

The  basic  elements  of  a feedback  function  are  included  in  the  require- 
ments. Gathering/reporting  information;  analysis,  evaluation,  and  measure- 
ment; corrective  action;  communications;  and  acknowledgement  are  provided  for. 
The  principal  areas  of  concern  are  those  related  to  the  diversity  of  existing  dis- 
crepancy reporting  systems,  as  there  is  no  central  Navy  control  structure  in 
this  area,  and  the  communications  needs  of  an  effective  feedback  system. 

In  regard  to  the  existing  discrepancy  reporting  systems  for  MOTD,  they 
range  from  an  old  method  of  uncertain  effectiveness  to  a new  method  yet  to  be 
evaluated.  The  old  method  uses  the  comment  sheet  bound  into  printed  manuals, 
while  the  new  method  has  a separate  deficiency  report  form  (locally  available). 
There  are  other  methods,  previously  discussed  in  the  NTIPP  Task  1 report,  but 
these  two  are  the  principal  on-going  MOTD  reporting  systems.  The  overall  effec- 
tiveness of  each  may  be  high  or  low;  no  statistical  data  was  uncovered  during 
NTIPP  research.  The  effectiveness  of  the  several  types  of  methods  used,  in- 
cluding the  above,  needs  to  be  determined  to  define  this  key  element  of  a feed- 
back system.  The  feedback  organizational/functional  structure  must  provide  the 
capability  (or  direction)  to  perform  this  R&D.  It  follows  that  when  the  most  ef- 
fective methods  and  techniques  are  determined  and  developed,  they  should  be 
employed  throughout  the  Navy. 

Tying  together  all  of  the  interfaces  of  a feedback  system  requires  an 
available  efficient  communications  capability.  It  must  be  easy  for  the  reporter 
to  get  his  report  of  discrepancy  to  the  point  where  action  can  be  taken.  General- 
ly, this  link  in  the  network  must  be  through  some  levels  of  local  authority  to 
maintain  an  information  chain.  This  is  often  a single  individual  or  office  which  is 
assigned  the  responsibility  to  monitor  deficiency  (or  even  efficiency)  operational 
data.  There  should  be  no  delays.  This  link  is  used  for  the  return  corrective 
action  cycle,  and  also  for  the  acknowledgement  to  the  reporter,  both  of  which 
are  equally  important. 

One  approach  to  consider  for  feedback  is  to  use  the  distribution  network 
for  feedback  communications,  since  it  already  connects  the  user  to  the  source 
of  MOTD.  However,  no  matter  how  good  the  communications  element,  the  feed- 
back system  will  not  satisfy  its  overall  requirement  without  its  other  functional 
elements.  An  authoritative  structure  must  exist  to  insure  the  corrective  meas- 
ures are  taken  and  acted  upon  to  satisfy  the  seriousness  of  the  discrepancy.  The 
present  priorities  for  critical  or  urgent  corrective  action  should  remain.  Less 
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critical  defects  in  MOTD,  now  corrected  routinely,  may  need  two  time  cycles  — 
one  for  content  items  such  as  missing  (but  not  critical)  information,  and  another 
for  mechanical  items  such  as  typographical  errors  which  do  not  affect  context. 

Also  very  important  is  to  provide  an  acknowledgement  system  so  that  the  reporter, 
and  those  he  relates  with,  know  the  system  is  working.  This  can  increase  credi- 
bility and  provide  a stimulus  to  the  use  of  the  system. 

All  of  these  elements,  along  with  consideration  of  existing  systems  and 
centralization  factors,  will  be  included  as  the  baseline  and  alternatives  are  de- 
fined, analyzed,  and  compared  in  developing  the  NTIPP  feedback  system  of 
the  1980s, 

TABLE  4-VIII.  FEEDBACK  REQUIREMENTS 


To  provide  a standardized' system  for  user  feedback  with  common  methods, 
policies,  and  procedures. 

To  develop  standard  information  reporting/gathering  mechanisms,  using 
combinations  of  techniques  such  as  user-initiated  forms,  forms  accompany- 
ing media,  mail-back  survey  questionaires,  and  person-to-person  surveys. 

To  develop  and  provide  the  organizational/functional  capability  to  analyze, 
evaluate,  and  measure  discrepancy  (or  other  TM-related  data  to  determine 
and  report  needed  action,  monitor  program,  record  for  trend  analysis,  con- 
tinually assess  feedback  system  effectiveness,  and  perform  R&D  in  all 
functional  areas  of  feedback  systems. 

To  develop  and  provide  timely  and  effective  corrective  action  mechanisms 
to  implement  the  needed  actions,  using  such  methods  as  direct  communica- 
tions to  users  for  imperative  action,  and  normal  routine  communications 
media  for  other  corrective  action. 

To  develop  and  provide  methods  of  acknowledgement  to  participants  in  the 
discrepancy  report  program  using  routine  (but  time-limited)  communications. 

To  provide  communications  to  net  the  user  (discrepancy  reporter)  to  the 
source  of  MOTD  through  the  layers  of  organizations  and  related  authorities 
as  needed  for  reporting/gathering,  corrective  action,  and  acknowledgement, 
using  such  means  conventional  communications  channels  and  considering 
adoption  of  the  MOTD  distribution  network. 

To  accumulate  and  report  management  information  such  as  numbers  and 
types  of  discrepancies,  time  of  response,  trends,  and  program  costs,  and 
other  related  data. 
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Section  4 - Research  Issue  Level  NTIPP  Requirements 


4.9  INTEGRATION  REQUIREMENTS 


The  integration  issue  encompasses  all  the  requirements  necessary  to  implement 
NTIPP  as  an  operational  system.  These  requirements  provide  the  basis  for 
NTIPP  administration,  coordination  of  interfaces  among  various  NTIPP  elements, 
and  coordination  of  NTIPP  interfaces  with  the  weapon  system  acquisition  process 
and  integrated  logistic  support  activities. 

Integration  requirements  for  NTIPP  administration,  shown  in  Table  4-IX, 
provide  for  analysis,  coordination  and  support  of  the  operational  system.  These 
requirements  are  allocated  and  structured  to  enable  NTIPP  to  produce  MOTD 
efficiently  and  economically.  They  establish  uniform  guidance  for  the  prepara- 
tion of  MOTD  that  meets  the  user  needs,  and  ensure  that  delivered  MOTD  reflects 
the  correct  equipment  configuration. 

The  System  Management  function  provides  for  budgeting,  distribution  of 
funds,  and  staffing  of  the  TM  acquisition  activities.  Additionally,  higher  level 
interfaces  with  Navy,  DoD  and  industry  representatives,  critical  to  efficient 
NTIPP  operation,  are  accomplished  by  this  function. 

The  purpose  of  the  System  Engineering  function  is  to  produce  the  specifi- 
cation architecture  which  sets  the  policy  and  guidance  necessary  for  the  produc- 
tion of  detailed  specifications  at  the  TM  acquisition  activities.  This  approach 
provides  uniformity  of  MOTD  content  treatment  while  allowing  for  differences  in 
detailed  treatment  of  MOTD  for  particular  user/equipment  needs. 

The  Research  and  Development  function  investigates  new  hardware  devel- 
opments, assess  new  findings  in  the  field  of  human  engineering,  and  serves  as 
an  MOTD  presentation  media  evaluation  laboratory. 

The  policies  and  directives  that  coordinate  the  activities  of  the  NTIPP 
elements  are  issued  by  the  System  Design  functions.  Additionally,  this  function 
is  responsible  for  modifying  the  NTIPP  design  in  order  to  maintain  and  improve 
efficiency  as  system  requirements  change. 

The  TM  Utilization  function  monitors  user  feedback  reports  and  hardware 
configuration  status  reports  in  order  to  ensure  that  required  MOTD  updates  are 
implemented  and  distributed  to  the  field. 

The  current  lack  of  valid  TM  cost  data  dictates  that  cost  monitoring, 
in-depth  analysis,  life  cycle  cost  s\ r hesis  and  other  cost  type  information  be 
made  available  for  Navy-wide  use.  7 he  Cost  Analysis/Forecasting  and  Report- 
ing function  performs  these  tasks,  as  well  as  monitoring  of  NTIPP  element  costs 
in  order  to  maintain  their  cost-effective  structure. 

The  rationale  and  requirements  for  NTIPP  interfaces  with  the  Weapon 
System  Acquisition  Process  and  Integrated  Logistic  Support  Activities  are 
detailed  in, Section  3.  These  requirements,  both  reactive  and  derived,  are  sum- 
marized in  Table  4-IX. 


TABLE  4-IX.  INTEGRATION  REQUIREMENTS 


NTIPP  ADMINISTRATIVE  REQUIREMENTS 


General  Requirement 

Detailed  Requirement 

• System  Management 

• Staffing  of  TM  Acquisition  Activities 

• Budgeting  and  Distribution  of  Funds 

• Coordination  of  NTIPP  Activities  with 
Navy,  DoD,  and  Industry 

• Long  Range  Planning 

• System  Engineering 

• Specification  Architecture 

• TM  Element  Design 

• User-Data  Match  Implementation 

• Head/Data /Training  Trade-Off 
Implementation 

• Research  and  Development 

• Hardware  Technology  Assessment 

• Human  Engineering  Assessment 

• Industry’  Research  and  Development 
Interface 

• Media  Evaluation 

• Logistic  Support  Technology  Assessment 

• System  Design 

• TM  Effectiveness  Evaluation 

• Policy  and  Directives 

• Coordination  of  Interfaces  Among  Various 
NTIPP  Elements 

- Data  Acquisition 

— Content  Generation 
— Content  Capture 

- Content  Replication 
— Distribution 

— Feedback 
— Update 

• TM  Utilization 

• Configuration  Management 

• Distribution  Policy 

• Cost  Analysis/Forecasting  and 
Reporting 

• Life  Cycle  Costs 

• Cost  Monitoring 
— TM  Costs 

- NTIPP  Costs 
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Section  4 — Research  Issue  Level  NTIPP  Requirements 


4.9  INTEGRATION  REQUIREMENTS  (Continued) 

TABLE  4-DC.  INTEGRATION  REQUIREMENTS  (Continued) 


CONCEPT  FORMULATION  PHASE 


Reactive  Requirements 

Derived  Requirements 

• Define  MOTD  requirements  with  respect 
to  the  operational  and  support  capability 
of  proposed  system 

• Formulate  general  MOTD  requirements  to 
support  proposed  system  based  on: 

— System  complexity 

— System  maintainability  characteristics 
— User  characteristics 
— Environmental  characteristics 
— Maintenance  philosophy 
— Maintenance  task  characteristics 
— MOTD  presentation  media 
— MOTD  presentation  techniques 
- Number  of  systems 

• Establish  candidate  MOTD  concepts 
derived  from  analysis  of  general 
MOTD  requirements 

• Formulate  MOTD  guidance  concepts  as 
follows: 

- Develop  publications  tree 

- Perform  Head/Data/Training  Trade-off 
— Perform  User-Data  Match 

— Define  readability/comprehensibility 
requirements  for  text  and  graphics 
— Define  presentation  medias 

- Define  distribution  methodology 

- Define  validation/verification 
parameters 

- Define  update  methodology 

- Define  feedback  origins  and  methodology 

• Select  viable  MOTD  concepts  for  con- 
sideration during  validation  phase 

• Perform  gross  cost/effectiveness  analysis 
bounded  by  affordability  and  capabilities  of 
existing  support  system 

• Develop  planning  necessary  to  imple- 
ment MOTD  concepts  for  proposed 
system 

• Formulate  for  development  and  production 
of  MOTD  concepts  as  follows: 

- Schedule  review  of  publication  planning 
documents 

- Schedule  in-process  reviews 

- Schedule  draft  MOTD  completion 

- Schedule  validation/verification 

- Schedule  final  MOTD  deliver}’ 

— Schedule  update  cycles 

TABLE  4-IX.  INTEGRATION  REQUIREMENTS  (Continued) 
VALIDATION  PHASE 


Reactive  Requirements 


Derived  Requirements 


• Develop  formal  MOTD  requirements 
which  meet  proposed  system  support 
concept 


• Establish  criteria  for  assessing 
compliance  with  MOTD  development 
requi  rements 


• Evaluate  proposed  approaches  for 
adherence  to  MOTD  requirements 
based  on  established  criteria 


• Establish  specific  MOTD  development 
requirements  for  support  of  proposed 
system  as  follows: 

— Validate  preliminary  data  used  to  form- 
ulate general  MOTD  requirements 

- Finalize  MOTD  guidance  concepts 

— Select  family  of  MOTD  specifications 

• Define  criteria  for  evaluation  of  proposed 
approaches  with  respect  to  meeting  MOTD 
requirements  as  follows: 

— Assess  risks 

- Establish  risk  boundaries 

— Establish  MOTD  test  parameters 
— Establish  validation/verification 
parameters 

- Prepare  MOTD  input  to  RFP 

• Perform  trade-off  analysis  of  MOTD  pro- 
posals based  on: 

— Publications  tree  coverage 
— Validation/Verification  plan  coverage 
— Compliance  with  User-Data  Match, 
training,  and  maintenance  philosophy 
requirements 

- Recognition  of  impact  of  other  related 
support  elements 

- Management  risks 

- Cost 

- Cost  control 

— Cost  collection 


Section  4 — Research  Issue  Level  NTIPP  Requirements 


4.9  INTEGRATION  REQUIREMENTS  (Continued) 

TABLE  4-EX.  INTEGRATION  REQUIREMENTS  (Continued) 


FULL-SCALE  DEVELOPMENT  PHASE 


Reactive  Requirements 

Derived  Requirements 

• Establish  interface  with  selected  con- 
tractor to  provide  guidance  and  insure 
compliance  with  stated  MOTD  concept 

• Review  and  assess  contractor  plans  and 
schedules  for  the  following: 

— Inherent  risk  in  plans  and  schedules 
— Maintaining  costs  within  established 
bounds 

— Completeness  of  publications  tree 
coverage 

— Identification  and  development  of  addi- 
tional equipment  manuals 
— Compliance  with  established  User-Data 
Match,  training,  maintenance  philosophy 
criteria 

— Consideration  of  impact  of  other  related 
support  activities 

— Validation/verification  considerations 

• Conduct  in-process  reviews  to  insure 
contractor  compliance  with  established 
plans  and  schedules,  and  to  assess 
compatibility  with  overall  system 
development 

• Review  and  assess  the  following: 

— Variance  from  established  plans  and 
schedules 

— Risks  incurred  and  anticipated 
— Costs  incurred  and  anticipated 
— Actual  compliance  with  User-Data  Match, 
training,  and  maintenance  philosophy 
criteria 

— Actual  impact  of  other  related  support 
elements  on  MOTD  development 
— Cost  and  schedule  reporting 

• Review  preliminary  MOTD  and  verify 
compliance  with  requirements 

• Assess  preliminary  MOTD  with  respect  to 
the  following: 

— Compliance  with  stated  requirements 
— Variance  of  risks  form  prescribed 
bounds 

— Cost  variance 
— Schedule  variance 

— Variance  from  User-Data  Match,  train- 
ing, and  maintenance  philosophy  criteria 
— Variance  from  planned  impact  of  other 
related  support  activities 
— Compliance  with  validation/verifi cation 
criteria 

— Plans  and  schedules  for  user  feedback 
and  update 

TABLE  4 -IX.  INTEGRATION  REQUIREMENTS  (Continued) 


PRODUCTION/DEPLOYMENT/SUPPORT  PHASES 


Reactive  Requirements 

Derived  Requirements 

• Establish  plans  and  schedules  for 
production  of  final  MOTD 

• Review  and  assess  contractor  plans  and 
schedules  for  the  following: 

— Risk  acceptability 

— Cost  bounds  and  acceptable  variables 
— Completeness  of  publications  tree 
coverage 

— Compliance  with  established  User-Data 
Match,  training,  and  maintenance 
philosophy  criteria 

— Consideration  of  impact  of  other  related 
support  activities 

— Validation/Verification  considerations 

• Conduct  in-process  reviews  to  insure 
contractor  compliance  with  estab- 
lished plans  and  schedules 

• Review  and  assess  final  MOTD  preparation 
with  respect  to  the  following: 

— Risk  management 
— Cost  management 

— Compare  MOTD  completed  to  date  with 
finalized  publication  tree 

— Variance  from  User-Data  Match,  train- 
ing, and  maintenance  philosophy  criteria 

— Variance  from  planned  impact  of  other 
related  support  elements 

— Validation/verification  status 

• Review  final  MOTD 

• Verify  compliance  with  requirements 

• Assess  final  MOTD  with  respect  to  devia- 
tion from  plan  as  follows: 

— Risk  variance 
— Cost  variance 

— Variations  from  final  publications  tree 
- Variance  from  User-Data  Match,  train- 
ing, and  maintenance  philosophy  criteria 
— Variance  from  planned  impact  of  other 
related  support  elements 

• Replicate  and  distribute  final  MOTD 
to  using  activities 

• Implement  plans  for  final  MOTD  replication 
and  distribution  as  follows: 

— Training  activities  in  accordance  with 
training  schedules 

— Fleet  user  activities  in  accordance  with 
equipment  deployment  schedule 
- Cognizant  support  and  administrative 
activities  storage 

• Establish  feedback  channels  for  moni- 
toring MOTD  user  complaints  and 
initiate  update  cycle 

• Implement  user  feedback  and  MOTD  update 
cycle 

- Evaluate  effectiveness  from  User-Data 
Match  and  training  viewpoints 
— Evaluate  quality  control  effectiveness 
— Assess  required  corrective  actions 
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SECTION  5 

REFINEMENT  AND  RATIFICATION  OF  NTIPP  REQUIREMENTS 


1 Provisions  for  Navy  Review  of  NTIPP  Requirements 


Section  5-  Refinement  and  Ratification  of  NTIPP  Requirements 


5.1  PROVISIONS  FOR  NAVY  REVIEW  OF  NTIPP  REQUIREMENTS 


The  principal  mechanism  for  Navy  review  of  the  preliminary  NTIPP  requirements 
was  individual  review  of  the  draft  Task  2 report,  coupled  with  joint  discussion  and 
coordination  at  the  February  1977  NTIPP  In-Process  Review.  To  enhance  this  set 
of  NTIPP  requirements,  reviewers  were  encouraged  to  indicate  modifications,  addi- 
tions, and  deletions  as  appropriate. 

A thorough  Navy  review  of  preliminary  NTIPP  requirements  is  critical 
to  the  subsequent  phases  of  NTIPP  Phase  I,  since  these  requirements  serve  as 
the  chief  means  for  qualifying  Task  3 alternatives  as  viable  candidates  for  con- 
sideration in  the  iterative  baseline  process.  Instructions  to  Navy  reviewers  were 
contained  in  a cover  letter  accompanying  the  report,  over  the  signature  of  NTIPP 
Technical  Director  R.  A.  Sulit,  David  W.  Taylor  Naval  Ship  Research  and  Devel- 
opment Center,  Code  18(JA,  dated  18  January  1977. 

Review  comments  generated  under  provisions  of  the  above-relereneed 
cover  letter  were  invoked  rvt  the  NTIPP  In-Process  Review  on  February  1G-17, 
1977,  at  the  contractor's  facility  in  Fullerton,  California.  After  discussion, 
appropriate  additions  deletions,  and  modifications  were  incorporated  into  the 
preliminary  NTIPP  requirements  documented  herein.  The  resultant  agreed-upon 
requirements  exist  in  the  form  of  this  final  issue  of  the  Task  2 report. 


SECTION  6 
CONCLUSIONS 


Section  6 — Conclusions 


In  developing  the  NTIPP  requirements,  it  was  noted  that  current  ILS  literature 
relating  MOTD  to  system  design  is  inadquate  in  scope  and  totally  lacking  in  definitive 
application  guidance.  The  critical  nature  of  the  Head/Training/Data  Trade-off 
requires  consideration  be  given  to  adding  definition  to  ILS  documentation. 

A major  effort  of  this  task  was  to  review  the  interface  between  the 
Weapons  system  Acquisition  Process  (WSAP)  and  to  postulate  as  requirements 
the  MOTD  steps  analogous  to  milestones  in  the  system  design  process.  Initial 
steps  concerning  the  definition  of  MOTD  in  the  Concept  Formulation  of  a given 
weapons  are  related  to  the  system  complexity,  user-data  match,  training,  speci- 
fication, and  maintenance  philosophy.  It  is  evident  that  NTIPP  cannot  accomplish 
these  steps  without  considerable  rapport  with  the  other  "ILS  Disciplines."  A 
Head/Training/Data  trade-off  cannot  proceed  without  definitions  and  input  from 
those  concerned  with  training  and  personnel.  These  entities  may  be  fully  prepared 
to  respond  to  this  need  most  effectively;  however,  evidence  to  support  this  need 
could  not  be  found.  Thus,  it  is  concluded  that  an  actual  Head/Training/Data 
Trade-off  cannot  really  be  accomplished  unless  the  other  disciplines  are  capable 
of  providing  the  needed  input. 

It  was  also  necessary  to  consider  the  "ILS  Discipline"  in  some  depth  as 
the  link  transform  between  NTIPP  and  WSAP.  ILS  documentation  is  sadly  lacking 
in  detail  as  to  what  actions  should  be  taken  in  the  early  stages  of  WSAP  and  the 
"how  to"  words  are  totally  lacking.  ^ In  many  cases,  the  ILS  literature  is  detailed 
in  support  of  production  hardware  in  that  it  is  a continuous  ) statement  of  the 
obvious.  The  effort  to  date  on  NTIPP  has  focused  upon  the  MOTD  requirements. 
Wherever  interfaces  to  other  disciplines  are  detected,  these  have  been  noted.  It 
is  beyond  the  purview  of  NTIPP  to  develop  the  processes  necessary  for  these 
related  areas  to  achieve  an  effective  interface;  however,  many  interfaces  are- 
felt  to  be  sadly  lacking  from  a responsive  viewpoint. 

In  addition  to  the  absence  of  "how  to"  words  in  the  ILS  documentation, 
there  is  an  absence  of  criteria  to  determine  the  qualification  oi  the  personnel 
who  will  accomplish  these  specialized  tradeoffs  in  WSAP.  Often  the  ILS  planning 
literature  refers  to  an  "ILS  team,"  but  nothing  exists  on  the  composition  of  this 
team  or  the  sources  from  which  personnel  will  be  selected.  Further,  nothing 
addresses  the  skill  levels  of  the  team  players;  apparently  anyone  with  some 
"Technical  Data"  or  "Training"  background  is  a qualified  candidate.  It  is  unclear 
as  to  what  qualifications  criteria  a Program  Manager  would  apply  to  selecting 
the  personnel  to  make  up  a given  "ILS  Team."  Considering  the  lack  of  intelligible 
direction,  it  is  little  wonder  that  ILS  as  a discipline  has  been  talked  about  for 
12  years  with  little  results  that  can  be  objectively  evaluated. 

It  is  clear  that  a Head/Training,  Data  Trade-off  is  essential  to  the  devel- 
opment of  "matched  MOTD."  This  tradeoff  is  based  upon  the  task  analysis,  the 
type  of  job,  the  frequency,  criticality,  complexity,  etc.  Currently,  the  ILS 
approach  places  task  analysis  in  the  MEA  or  ILS  world,  training  in  the  training 
world,  and  MOTD  in  the  "technical  manual"  world.  Yet,  these  must  be  effec- 
tively related  to  develop  the  rules  to  achieve  a "user-data  match.  " There  is  no 
question  that  this  type  of  tradeoff  can  be  made  in  the  "experimental"  mode  by 
carefully  selecting  the  team  and  the  target  system/equipment;  yet  one  wonders 
if  the  "real  world"  with  three  distinct  organizational  interfaces  can  effectively 
accomplish  this  trade-off  routinely. 


1.  NAVMATINST  4000.38  "Standard  Integrated  Support  Management  System," 
January  26,  1976. 
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Section  7 — Recommendations 


To  avoid  biasing  the  baseline  design,  the  recommendations  presented  here  treat  with 
aspects  that  impact  NTIPP,  yet  fall  beyond  its  purview.  

• A far  more  structured  and  cohesive  approach  which  treats  ILS  as  the 
transform  to  relate  the  support  technologies  to  the  Weapons  System 
Acquisition  Process  (WSAP)  is  essential. 

• Qualification  criteria  for  selecting  ILS  team  members  should  be 
developed  and  applied. 

• Development  of  training  and  personnel  selection  criteria  should  be 
undertaken  to  ensure  that  an  effective  User-Data  Match  can  be 
achieved  in  the  Head /Training/Data  Trade-Off  process. 

• Effort  should  be  expended  to  provide  specific  ILS  events  relative  to 
WSAP,  and  specific  methods  of  for  accomplishing  the  studies  support- 
ing these  events  should  be  determined. 
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GLOSSARY 


Abbreviation  or  Acronyn 


ADPREPS 

AIA 

ARI 

ATE 

BITE 

CDRL 

CNM 

COM 

DID 

DoD 

DSARC 

FBR 

FOMM 

GCT 


Full  Terminology’ 

-A- 

Automated  Document  Preparation  System 

Aerospace  Industries  Association 

Arithmetic  Reading  Index 

Automatic  Test  Equipment 
-B- 

Built-In  Test  Equipment 
-C- 

Contract  Data  Requirements  List 

Chief  of  Navy  Material 

Computer  Output  Microform 
-D- 

Data  Item  Description 

Department  of  Defense 

Defense  System  Acquisition  and  Review  Council 
-F- 

Feedback  Report 

Functionally  Oriented  Maintenance  Manuals 
-G- 

General  Classification  Test 


B-l 


-I- 


r 


r 
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ILS 

IPB 

IPR 

ITDT 

JCP 

JPA 

LCC 

LSA 

MEA 

MECH 

MDC 

MOTD 

NAVAIR 

NAVE LEX 

NAVMAT 

NAVSEA 

NAVSUP 

NPFC 

NPPSO 

NTIPP 

NTMS 


Integrated  Logistic  Support 
Illustrated  Parts  Breakdown 
In-Process  Review 

Improved  Technical  Documentation  and  Training 
-J- 

Joint  Committee  on  Printing 
Job  Performance  Aids 
-L- 

Life  Cycle  Cost 
Logistic  Support  Analysis 
-M- 

Maintenance  Engineering  Analysis 
Mechanical  Comprehension 
Maintenance  Dependency  Charts 
Maintenance  and  Operating  Technical  Data 
-N- 

Naval  Air  Systems  Command 

Naval  Electronics  System  Command 

Naval  Material  Command 

Naval  Sea  Systems  Command 

Naval  Supply  Systems  Command 

Navy  Publications  and  Forms  Center 

Navy  Publications  and  Printing  Services  Office 

Navy  Technical  Information  Presentation  Program 

Nav\'  Technical  Manual  System 


-v  vc 


-o- 


OCR 

OPNAV 

PMS 

RCA 
R & D 
RGL 
RFP 

SECNAV 

SECNAVINST 

SFTOA 

SYSCOM 

TM 

TMCR 

TRUMP 


UR 


VDT 


VVSAP 


Optical  Character  Recognition 
Chief  of  Naval  Operations 
-P- 

Planned  Maintenance  System 
-R- 

Radio  Corporation  of  America 
Research  and  Development 
Reading  Grade  Level 
Request  for  Proposal 
-S- 

Secretary  of  the  Navy 
Secretary  of  the  Nav>'  Instruction 
Systems  and  Feasibility  Tradeoff  Analysis 
Systems  Command 
-T- 

Technical  Manual 

Technical  Manual  Contract  Requirements 

Technical  Review  and  Update  of  Manuals  and 
Publications 

-U- 

Unsatisfactory  Report 
-V- 

Visual  Display  Terminal 
-W- 

Weapon  System  Acquisition  Process 
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